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The  overall  goal  of  the  Common  Ada  Missile  Packages  (CAMP)  program  Is 
to  demonstrate  to  the  DOD  software  engineering  community  that  software  parts 
which  are  reusable,  efficient,  and  simple  to  use  can  be  developed  for 
embedded  real-time  software  appl Iratlons .  The  application  area  In  which  CAMP 
will  demonstrate  the  feasibility  and  value  of  software  parts  Is  that  of 
missile  flight  software  systems.  I.1ko  most  embedded  real-time  applications, 
missile  flight  software  Is  severely  constrained  In  terms  of  memory  and  time. 
If  software  parts  can  be  developed  which  meet  the  stringent  requirements  of 
this  application  area,  then  the  utility  of  a  parts  approach  to  software 
engineering  for  other  real  time  embedded  applications  will  have  been 
establ 1  shed . 

The  past  decade  has  seen  the  Initiation  of  several  major  DUO  efforts 
designed  to  reduce  the  cost  of  developing  and  maintaining  mission  critical 
software  systems  while  at  the  same  time  Increasing  the  reliability  of  this 
software.  One  component  of  most  of  these  initiations  is  a  move  towards 
decreasing  the  amount  of  software  that  needs  to  be  developed  for  new 
applications.  An  obvious  way  to  decrease  the  amount  of  software  Is  to 
develop  software  parts  which  can  be  reused.  However,  until  recently  It  has 
been  commonly  believed  that  software  parts  were  not  feasible  for  embedded 
real-time  applications  because  they  could  not  be  built  efficiently  enough  to 
meet  the  needs  of  these  applications.  This  belief  has  been  based  on  the 
assumption  that  software  parts  must  be  general  to  be  useful  and  that 
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generality  Invariably  leads  to  inefficiency 

With  the  advent  of  Ada,  many  professional  software  engineers  believe  that 
the  time  has  arrived  when  software  parts  can  he  built  which  are  both  general 


enough  to  have  wide  applicability  and 
the  real  time  embedded  applications, 
designed  to  determine  the  validity  ot 
Phase  1  of  the  CAMP  program  was  a 
in  September  1984.  This  contract  was 
Force  Armament  Laboratory  (AFATL)  and 


efficient  enough  to  meet  the  needs  of 
The  first  phase  of  the  CAMP  program  was 
this  belief. 

12-month  feasibility  study  which  began 
sponsored  by  the  United  States  Air 
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Astronautics  Company  In  St.  Louis  (MDAC-STL).  The  Department  of  Oefense 
(DOD)  STARS  (Software  Technology  for  Adaptable,  Reliable  Systems)  program 
provided  partial  funding  for  this  contract. 

The  primary  objectives  of  the  first  phase  of  the  CAMP  program  were  (1)  to 
determine  the  feasibility  of  reusable  missile  software  parts  written  In  Ada, 
and  (2)  to  determine  the  feasibility  of  an  automated  software  parts 
composition  system  (l.e.,  a  tool  which  would  automate  or  semi-automate  the 
process  of  building  a  new  software  system  using  existing  software  parts).  If 
the  parts  and/or  the  parts  composition  system  proved  feasible,  then  they  were 
to  be  designed  during  CAMP.  In  addition  to  these  primary  objectives,  the 
following  tasks  were  performed  In  Phase  1  of  CAMP:  (1)  the  development  of  a 
missile  software  parts  cataloging  scheme;  (2)  an  evaluation  of  the  utility  of 
expert  systems  In  the  software  parts  engineering  process;  (3)  an  evaluation 
of  the  Japanese  software  reusability  efforts;  and  (4)  an  evaluation  of  the 
STARS  data  collection  forms. 

The  work  performed,  the  results  obtained,  and  the  conclusions  reached 
during  the  first  phase  of  CAMP  are  described  In  detail  In  Volumes  I  through 
III  of  this  technical  report.  Some  of  the  major  conclusions  reached  during 
the  CAMP-1  contract  are  discussed  In  the  subsequent  paragraphs. 

Sufficient  commonality  does  exist  (albeit  well  disguised)  within  missile 
software  systems  to  Justify  the  development  of  reusable  software  parts. 

During  the  CAMP  domain  analysis  over  200  reusable  missile  software  parts  were 
Identified.  These  parts  range  from  straightforward  mathematical  routines  to 
relatively  complex  parts  for  navigation  and  guidance  functions. 

Ada  Is  well  suited  for  building  software  parts  which  are  reusable, 
simple  to  use,  and  protected  against  misuse.  While  Ada's  advanced  features 
(e.g.,  packages,  overloading,  etc.)  are  complex  to  master,  they  give  the 
software  part  developer  the  tools  he  needs  to  develop  truly  reusable  parts 
which  are  simple  to  use.  All  the  complexity  Is  hidden  from  the  user  behind  a 
simple  Interface.  The  use  of  strong  data  typing  allows  the  construction  of 
parts  which  are  protected  against  misuse. 


Parts  can  be  developed  In  Ada  which  are  efficient  enough  for  real-time 
embedded  applications  while  still  being  reusable  and  simple  to  use.  The 
Issue  of  efficiency  was  of  prime  Importance  during  CAMP  as  the  parts 
designed  had  to  be  useful  In  an  area  where  memory  and  time  are  both  severely 
constrained.  While  the  mainframe  software  developer  might  be  willing  to 
sacrifice  a  degree  of  efficiency  in  order  to  achieve  an  increase  in  software 
development  productivity,  the  real-time  embedded  programmer  cannot  afford 
this  sacrlf 1ce--he  wants  both  efficiency  and  productivity.  During  CAMP,  a 
method  of  using  the  advanced  features  of  Ada  was  developed  that  would  allow 
the  construction  of  reusable  software  parts  which  were  as  efficient  as 
equivalent  application-specific  Ada  components. 

There  are  significant  benefits  associated  with  reusable  software 
parts.  During  CAMP  an  analysis  was  performed  to  determine  the  potential 
benefit  of  reusing  software.  This  analysis  demonstrated  that  relative  small 
degrees  of  reuse  can  result  In  significant  productivity  Improvements  and  that 
the  availability  of  tools  to  decrease  the  cost  of  reusing  parts  would 
significantly  Increase  software  productivity. 

Developing  good  reusable  software  parts  Is  more  expensive  than 
developing  customized  software  and  required  special  expertise.  A  software 
part  which  must  be  reusable,  efficient,  and  simple  to  use  requires  a  great 
deal  of  Ada  expertise  to  build.  In  addition.  It  requires  Insight  Into  the 
application  area.  Experience  on  CAMP  Indicated  that  It  would  be  unrealistic 
to  expect  mainstream  projects  to  develop  parts  within  the  project  because  of 
the  need  for  additional  resources  (expertise  and  effort).  Likewise,  It  would 
be  unrealistic  to  expect  an  Isolated  parts  group  to  develop  good  parts.  The 
Ideal  parts  development  group  would  be  a  separate  team,  but,  would  be  heavily 
Influenced  and  directed  by  ongoing  projects.  Although  reusable  parts  are 
more  expensive  to  develop  than  one  shot  code,  the  benefits  of  reuse  justify 
their  development. 

Automated  tools  can  significantly  Increase  the  productivity  gains 
achieved  by  reusable  software  parts.  Part  of  the  aforementioned  benefit 
analysis  dealt  with  the  cost  of  reusing  software.  It  was  shown  that  small 
decreases  In  the  cost  of  using  the  parts  can  result  In  large  Increases  In 
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productivity.  Automated  tools  can  significantly  decrease  the  cost  of  using 
parts.  Three  areas  can  benefit  from  the  use  of  automated  tools:  Parts 
Identification,  Parts  Cataloging,  and  Component  Construction. 

The  Identification  of  existing  software  parts  Is  a  process  which  can, 
and  should,  be  automated.  The  software  parts  Identification  function  allows 
the  missile  software  engineer  to  Identify  reusable  software  parts  which  are 
appropriate  for  his  new  missile  application.  What  distinguishes  this 
function  from  a  simpler  parts  catalog  (which  was  also  developed  on  CAMP)  Is 
that  the  Identification  process  can  take  place  at  a  very  early  point  In  the 
missile  development  process.  This  early  Identification  of  applicable 
software  parts  Is  needed  to  facilitate  missile  design  trade-offs,  cost 
analyses,  and  sizing  and  timing  analysis.  In  effect,  this  function  allows 
the  user  to  map  missile  requirements  onto  a  set  of  parts.  The  Implementation 
of  this  function  Is  facilitated  by  the  use  of  Artificial  Intelligence 
techniques . 

The  construction  of  application-specific  software  components  from  parts 
which  capture  recurring  patterns  of  logic  can,  and  should,  be  automated. 
During  CAMP-1,  the  feasibility  of  providing  the  user  wl  1  the  ability  to 
automatically  generate  components  of  a  new  missile  software  system  was 
demonstrated.  The  generation  of  these  application-specific  software 
components  Is  accomplished  through  the  use  of  schematic  parts.  A  schematic 
part  Is  a  part  which  captures  a  recurring  pattern  of  logic  which  cannot  be 
Implemented  directly  In  Ada.  In  effect,  a  schematic  part  Is  a  blueprint 
together  with  a  set  of  construction  rules  which  specify  how  the  part  Is  to 
be  constructed  In  light  of  a  given  set  of  requirements.  The  CAMP  parts 
consist  of  three  types  of  parts:  simple,  generic,  and  schematic. 

Expert  Systems  have  great  potential  In  automating  the  software  parts 
engineering  process.  An  expert  system  Is  an  Artificial  Intelligence  system 
which  emulates  the  manner  In  which  human  experts  solve  problems.  During  CAMP 
we  constructed  a  proof-of-concept  Implementation  of  a  schematic  part 
constructor  using  the  Automated  Reasoning  Tool  (ART)  which  Is  a  commercial 
expert  system  tool.  We  also  verified  that  It  can  be  used  to  construct  the 
software  parts  catalog  and  the  software  parts  Identification  function 


previously  described.  By  using  an  expert  system,  later  phases  of  CAHP  will 
be  able  to  construct  a  software  parts  composition  system  which  Is  Intelligent 
and  flexible  and  hence  will  promote  the  use  of  the  CAHP  parts  and  the  best 
use  of  the  software  engineer's  time.  The  automated  software  parts 
composition  system  that  was  designed  during  CAMP  was  called  the  Ada  Missile 
Parts  Engineering  Expert  (AMPEE)  system.  This  system  provides  a  complete 
set  of  software  parts  engineering  functions  In  one  tool. 
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PREFACE 


This  report  describes  the  work  performed,  the  results  obtained,  and  the 
conclusions  reached  during  the  Common  Ada  Missile  Packages  (CAMP)  contract 
(F08635  84-C-0280).  This  work  was  performed  by  the  Computer  Systems  & 
Software  Engineering  Department  of  the  McDonnell  Douglas  Astronautics 
Company,  St.  Louis,  Missouri  (MDAC  STL),  and  was  sponsored  by  the  United 
States  Air  Force  Armament  Laboratory  (FXC)  at  Eglln  Air  Force  Base, 

Florida.  This  contract  was  performed  between  September  1984  and  September 
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f.  PURPOSE 

This  report  contains  a  description  of  the  work  performed  on  the  first 
phase  of  the  Common  Ada  Missile  Packages  (CAMP)  program.  This  was  a  12-month 
feasibility  study  sponsored  by  the  United  States  Air  Force  Armament 
Laboratory  (AFATL)  and  performed  by  the  McDonnell  Douglas  Astronautics 
Company  In  St.  Louis  (MDAC-STL).  The  CAMP  program  was  performed  during  the 
period  of  September  1984  through  September  1985.  The  CAMP  program  was 
partially  funded  by  the  Department  of  Defense  (000)  STARS  (Software 
Technology  for  Adaptable,  Reliable  Systems)  program. 

The  overall  goal  of  the  CAMP  program  Is  to  demonstrate  to  the  000 
software  engineering  community  that  reusable  software  parts  can  be  practical 
In  embedded  real-time  software  applications  such  as  missile  software 
systems.  The  first  phase  of  CAMP  had  two  specific  objectives:  to  determine 
the  feasibility  of  reusable  missile  software  parts  written  In  Ada;  and,  to 
determine  the  feasibility  of  an  automated  software  parts  composition  system. 

In  addition  to  these  primary  objectives,  the  CAMP  program  Involved  the 
performance  of  the  following  tasks. 

a.  The  development  of  a  missile  software  parts  cataloging  scheme. 

b.  An  evaluation  of  the  utility  of  expert  systems  In  the  software  parts 

engineering  process. 

c.  An  evaluation  of  the  Japanese  software  reusability  efforts. 

d.  An  evaluation  of  the  STARS  data  collection  forms. 
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2.  BACKGROUND 


During  the  past  10  years,  DOD  and  the  military  services  have  become 
Increas  Ingly  sensitive  to  the  critical  role  that  software  plays  In  mission 
critical  systems.  These  organizations  have  been  forced  to  accept  the 
existence  of  a  software  crisis  by  the  realization  that  software  has  been  a 
major  source  of  problems  In  defense  systems.  The  software  crisis  Is 
characterized  by:  (1)  rapidly  escalating  software  development  and 
maintenance  costs,  (2)  delays  In  deployment  of  new  defense  systems  due  to 
ever  expanding  software  development  schedules,  (3)  restrictions  on  the  number 
of  programs  which  can  be  developed  concurrently  due  to  a  shortage  of  software 
expertise,  and  (4)  reliability  problems  with  deployed  defense  systems  due  to 
poor  software  quality. 

The  basic  cause  of  the  software  crisis  Is  the  tremendous  Increase  In  the 
demand  for  software,  and  the  explosive  growth  In  the  size,  complexity,  and 
critical  nature  of  modern  software  systems.  This  crisis  has  resulted  In  a 
situation  where  existing  software  methods  and  tools  are  antiquated,  software 
engineers  are  under-trained  and  over-committed,  and  software  project  managers 
are  too  busy  handling  the  crisis  to  develop  sound  software  management 
procedures.  Obviously  such  a  complex  problem  has  no  one  solution,  but 
concrete  Initiatives  do  exist  which,  If  taken,  will  alleviate  the  current 
problems.  While  It  Is  beyond  the  scope  of  this  report  to  discuss  all  the 
Initiatives  which  are  being  proposed,  there  Is  one  common  factor  which  can  be 
found  In  most  of  these  Inltlatlves-the  reuse  of  software  parts.  The  CAMP 
program  was  motivated  by  the  potential  of  reusable  software. 

3.  SOFTWARE  REUSABILITY 

Simply  stated,  software  parts  are  pre-bullt  software  components  which 
have  been  explicitly  designed  to  be  used  (reused)  In  multiple  applications 
within  a  given  application  area  (see  figure  1).  Although  one  typically 
thinks  of  only  code  as  being  reusable,  this  Is  not  the  case.  Later  In  this 
report  It  shall  be  shown  that  a  software  part  can  be  any  software  entity 
which  Is  capable  of  reuse  (e.g.,  a  software  design  component,  a  series  of 
software  tests ,  etc  . ) . 
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Figure  1.  The  Use  of  Software  Parts  In  Missile  Software  Systems 

a.  The  Benefits  of  Software  Reuse 

The  potential  benefits  of  a  parts  approach  to  software  engineering 
are  quite  significant.  Software  reuse  can: 

(1)  Increase  software  development  and  maintenance  productivity, 

(2)  Lead  to  more  reliable  software,  and 

(3)  Help  conserve  critical  software  engineering  expertise. 

The  most  obvious  benefit  of  reusing  software  Is  that  less  code  needs 
to  be  developed  and  therefore  less  time  and  money  Is  required  for  the 
development  of  new  software  systems.  Even  a  modest  degree  of  software  reuse 
can  result  In  significant  cost  savings.  Figure  2  depicts  the  effect  of 
software  reuse  on  software  development  productivity. 
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THE  USE  OF  SOFTWARE  PARTS  CAN 
SIGNIFICANTLY  INCREASE  PRODUCTIVITY 


0%  20%  40%  60%  00%  100% 

PARTS  USAGE  COST  FACTOR 

Figure  2.  The  Effect  of  Software  Reuse  on  Development  Productivity 

It  can  be  seen  from  Figure  2  that  the  relationship  between  the 
amount  of  software  reused  and  the  resulting  productivity  Improvement  Is 
dependent  upon  a  parts  usage  cost  factor.  This  cost  factor  captures  the  cost 
of  finding  the  right  parts,  analyzing  the  parts,  and  developing  the 
application  software  to  Interface  with  the  parts  as  a  percentage  of  the  cost 
to  develop  the  soitware  parts  from  scratch,  figure  2  shows  that  If  one  could 
build  40  percent  of  a  new  software  system  using  available  parts,  and  the  cost 
factor  was  20  percent  (l.e.,  reuse  of  parts  costs  20  percent  more  than 
non  reuse),  then  a  50  percent  Increase  In  development  productivity  could  be 
achieved . 

Obviously  there  has  to  be  a  limit  to  the  amount  of  productivity  one 
can  gain  from  using  parts.  Figure  3  depicts  the  amount  of  productivity 
Improvement  (as  a  function  of  the  cost  factor)  that  can  be  expected  If  100 
percent  of  a  software  system  was  constructed  from  parts. 
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Figure  3.  The  Productivity  Gained  With  100  Percent  Software  Reuse 

According  to  Figure  3,  If  an  embedded  software  system  was  completely 
constructed  from  software  parts  (l.e.,  100  percent  reuse),  and  the  cost 
factor  was  55  percent  then  a  productivity  Improvement  of  100  percent  could  be 
expected.  The  rationale  behind  Figures  2  and  3  Is  discussed  In  Section  V. 
Since  maintenance  costs  (l.e.,  the  cost  to  correct  software  errors,  modify 
the  software  to  a  new  environment,  and  expand  the  capabilities  of  the 
software)  often  greatly  outweigh  the  development  costs  of  software,  a 
reduction  In  the  amount  of  code  to  be  maintained  can  result  In  drastically 
lower  product  life  cycle  costs.  As  with  any  software,  software  parts  will 
need  to  be  maintained.  There  are  two  factors  which  Indicate  that  the 
maintenance  of  software  parts  will  be  much  cheaper  than  the  maintenance  of 
custom  written  software:  the  cost  of  maintaining  the  parts  Is  amortized 
across  multiple  projects;  and,  errors  In  software  parts  will  be  found  much 
earlier  than  errors  In  customized  software  since  the  parts  are  receiving  more 
use.  The  earlier  an  error  Is  detected  the  cheaper  It  Is  to  correct  that 
error 
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If  software  parts  are  rigorously  tested  before  they  are  cataloged 
for  later  reuse,  then  the  reliability  of  the  new  software  systems  will  be 
Increased.  This  Is  especially  Important  since  the  Impact  of  software  errors 
In  parts  Is  much  higher  than  for  customized  software  since  the  errors  will 
affect  more  programs.  Without  vigorous  testing,  parts  developed  by  different 
people  at  different  times,  with  differing  degrees  of  reliability  will  not  be 
trusted. 

The  required  staffing  for  a  software  development  and/or  maintenance 
project  will  be  decreased,  assuming  a  significant  level  of  software 
reusability.  Given  the  shortage  of  software  engineers  that  exists  throughout 
the  Industry,  this  Is  a  major  advantage.  If  the  parts  Include  functions 
which  typically  require  a  high  degree  of  application  expertise  (e.g.t 
Guidance  &  Control),  then  a  project  can  perform  the  same  development  with 
fewer  software  engineers  experienced  In  the  application  area. 


b.  The  Barriers  to  Software  Reuse 

Given  all  the  aforementioned  benefits.  It  Is  only  natural  to  wonder 
why  software  has  not  been  reused  In  the  past.  The  answer  to  this  question  Is 
that  It  has,  but  only  to  a  very  limited  degree.  Almost  all  software  systems 
have  Incorporated  certain  types  of  software  parts.  The  most  common  type  of 
part  has  been  the  mathernat leal  part  (l.e.,  a  routine  from  a  math  library). 

Yet  If  this  type  of  low-level  reusability  was  all  that  could  be  hoped  for. 
the  benefits  discussed  earlier  would  not  be  fully  achievable. 

There  are  several  reasons  why  the  software  engineering  community  has 
not  been  able  to  achieve  a  meaningful  level  of  software  reuse  In  the  past. 

(1)  Our  programming  languages  have  not  had  the  facilities  to 
support  software  reusability. 

(2)  We  have  not  invested  the  time  and  effort  to  Identify  the 
commonality  In  software  systems. 

(3)  It  has  not  been  demonstrated  that  software  reuse  can  work  In 
embedded,  real-time  software  applications. 

(4)  We  have  not  encouraged  and/or  required  our  software  developers 
to  reuse  software  parts. 
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With  the  advent  of  Ada,  there  Is  now  a  computer  programming  language 
which  was  explicitly  designed  with  the  goal  of  software  reusability  In  mind. 
Specifically,  Ada  possesses  facilities  for:  transporting  programs  across 
machine  and  operating  system  boundaries;  enforcing  the  design  and 
construction  of  autonomous  software  units  with  clean,  well  designed 
Interfaces;  and,  developing  software  parts  which  are  generic  In  nature  and 
which  can  be  tailored,  using  the  Ada  language  Itself,  for  a  particular 
appl Icatlon. 

One  of  the  major  barriers  to  an  effective  software  reusability 
program  Is  the  need  to  conduct  an  In-depth  domain  analysis  of  the  application 
area  In  which  the  software  Is  to  be  reused.  A  domain  analysis  Is  an 
examination  of  a  specific  application  area  which  seeks  to  Identify  common 
operations,  objects,  and  structures  which  are  candidates  for  software  parts. 
Domain  analyses  are  not  cheap  to  perform.  They  require  an  Intensive 
examination  of  existing  software  systems  within  the  application  area  being 
studied,  and  personnel  skilled  both  In  modern  software  development  techniques 
and  In  the  application  area.  Yet,  to  attempt  to  start  a  software  reusability 
program  without  adequately  performing  this  analysis  Is  as  foolish  as 
attempting  to  design  a  software  system  without  performing  an  analysis  of  the 
software  requirements. 

It  has  long  been  a  belief  of  the  real-time,  embedded  software 
engineering  community  that  reusable  software  parts  could  not  work  In  their 
application  area.  This  belief  has  been  based  on  the  assumption  that  software 
parts,  by  necessity,  must  be  general  enough  to  allow  broad  use.  The 
Implication  of  this  observation  Is  that  efficiency  Is  lost  when  generality  Is 
sought.  In  the  past  this  Implication  has  been  true,  however  this  no  longer 
need  be  true.  There  are  two  factors  which  have  changed  the  picture:  the 
advent  of  modern  compilers  with  advanced  optimization  features;  and  the 
advent  of  Ada  which  allows  generality  without  high  losses  In  efficiency. 

Modern  compilers  can  now  detect  and  correct  Inefficiencies 
Introduced  In  source  programs  In  order  to  obtain  generality.  For  example, 
most  modern  compilers  will  allow  a  subroutine  to  be  expanded  Inline  thereby 
allowing  the  subroutine  to  be  reusable  without  Incurring  the  overhead  of  a 
subroutine  call.  The  Ada  generic  facility  allows  the  creation  of  tallorable 
software  parts  which  provide  a  good  degree  of  generality  while  still  being 
efficient.  For  example,  a  single  generic  package  can  be  built  which  would  be 
capable  of  buffering  any  data  object  without  any  loss  In  runtime  efficiency. 
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One  of  the  thorniest  Issues  which  arises  In  every  reusable  software 
effort  and  which  can  cause  a  total  failure  of  the  effort  Is  the  need  to 
enforce  the  reuse  of  parts.  Without  reuse,  the  development  of  reusable 
software  parts  becomes  an  exercise  In  futility  and  any  additional  cost 
Incurred  to  develop  these  parts  (as  opposed  to  one  shot  code)  cannot  be 
amortized.  Simply  stated,  programmers  do  not  like  to  reuse  software 
because:  programmers  feel  that  reusing  parts  lessens  their  creative  role  In 
the  development  of  software  systems;  they  have  little  faith  In  the 
correctness  of  reusable  parts;  they  are  not  aware  of  the  existence  of 
reusable  parts;  they  find  the  software  parts  difficult  to  understand  and/or 
reuse  In  comparison  to  developing  new  software,  and  they  feel  that  they  can 
build  a  better  part. 

The  key  factors  In  overcoming  the  reluctance  of  programmers  to  reuse 
pre  built  software  parts  are  discipline,  knowledge,  tools,  and  management 
commitment  (see  Figure  4). 


MANAGEMENT 

COMMITMENT 


KNOWLEDGE 

Figure  4.  The  Keys  to  Overcoming  Programmer  Reluctance  to  Reuse  Software 


Discipline:  A  successful  software  parts  program  must  Involve  the 
Imposition  of  a  high  degree  of  parts  usage  discipline  within  the 
organization.  This  discipline  must  be  enforced  by  reviews  and  audits. 


Knowledge:  Programmers  must  also  have  the  knowledge  that  parts 
exist  and  that  they  have  been  validated.  Just  as  hardware  designers  are 
expected  to  know  which  parts  are  available,  professional  software  engineers 
should  be  expected  to  know  about  software  parts. 

Tools :  Automated  tools  are  an  essential  aspect  of  a  software 
reusability  program.  They  free  the  software  engineer  from  mundane, 
mechanical  chores  associated  with  using  parts,  thus  Increasing  productivity. 
These  tools  should  facilitate  the  retrieval  of  appropriate  parts,  the 
generation  of  new  parts,  the  composition  of  software  systems  with  existing 
parts,  and  a  wide  variety  of  other  functions  relating  to  parts  usage. 

Management  Commitment:  Managers  will  support  a  software  reusability 
program  only  when  It  becomes  apparent  that  reuse  will  cut  costs  and  Increase 
profits;  000  reuse  Incentives  and/or  the  removal  of  reuse  disincentives  to 
contractors  could  significantly  Impact  management  commitment. 

c.  The  Challenge 

The  reuse  of  software  parts  offers  the  promise  of  dramatic  Increases 
In  software  development  and  maintenance  productivity.  Yet  this  promise  can 
only  be  achieved  If  an  organization  Is  working  In  an  application  area  which 
has  a  significant  degree  of  commonality,  sufficient  time  and  effort  are 
Invested  to  exploit  this  commonality  by  developing  parts,  and  the  tools  and 
methods  needed  to  enforce  a  software  parts  engineering  discipline  are  put  In 
place. 


4.  ASSUMPTIONS 

The  CAMP  program  was  based  on  several  assumptions  which  are  believed  to 
be  true  but  cannot  be  proven  true  at  this  time. 

a.  Ada  will  be  the  primary  language  used  to  develop  future  missile 
software  systems. 

b.  Ada  compilers  will  produce  object  code  sufficiently  efficient  for 
missile  software  systems. 

c.  Since  commonality  exists  In  current  missile  software  systems,  then 
It  will  exist  In  future  missile  software  systems. 
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Although  the  use  of  Ada  on  mission  critical  system  has  been  mandated  by 
DOD  directive,  the  reality  of  the  situation  Is  that  Ada  will  only  be  used  If 
compilers  and  associated  tools  are  available  and  efficient.  At  the  current 
time,  great  progress  Is  being  made  on  efficient  Ada  compilers  and  support 
tools  are  In  development.  The  compilers  which  are  being  developed  compare 
very  well  to  the  best  compilers  for  more  established  Higher  Order  Languages 
such  as  FORTRAN. 

Missiles,  like  most  other  products,  tend  to  evolve  In  generations,  (see 
Figure  5).  As  will  he  discussed  In  subsequent  parts  of  this  report,  the  CAMP 
project  examined  current  missile  software  systems  and  to  some  degree  the 
trends  which  were  known  to  exist  which  might  affect  future  missile  software 
systems.  However,  the  Implication  that  If  commonality  exists  In  current 
missiles  then  commonality  will  exist  In  future  missile  cannot  be  proven. 


5.  UTILITY  GOALS 

Because  of  the  relative  Immaturity  of  the  software  engineering 
discipline,  the  software  Industry  has  been  plagued  with  tools  and  methods 
which  are  less  than  useful.  Frequently  It  seems  as  If  people  are  busy 
developing  solutions  for  theoretical  rather  than  real  problems.  In  order  to 
avoid  the  occurrence  of  this  situation  In  the  CAMP  program,  a  number  of  goals 
were  established  for  both  the  parts  development  task  and  the  automatic  tool 
definition  tasks. 


GENERATION  N  *  1 


figure  5  The  Evolution  of  Missile  Software  Systems 
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a.  Parts  Utility 


The  following  goals  were  set  to  establish  the  utility  of  software 
parts  Identified  In  the  CAMP  project. 

(1)  A  software  part  must  provide  a  useful  function  to  more  than  one 
potential  application. 

(2)  The  use  of  parts  should  result  In  little,  If  any,  loss  of 
runtime  efficiency. 

(3)  The  use  of  parts  should  be  simple. 

(4)  The  use  of  parts  should  allow  flexibility. 

In  the  CAMP  context,  a  software  part  Implicitly  Implies  that  It  Is 
Intended  for  reuse.  However,  great  care  must  be  taken  to  avoid  developing 
parts  which  are  not  useful  to  a  sizable  application  area.  For  example,  a 
generic  part  which  would  perform  the  function  X  =  A  *  B  -  C  for  any  A,  B,  or 
C  might  have  the  potential  of  high  use,  but  would  not  be  useful.  On  the 
other  hand,  developing  parts  which  have  little  possibility  of  being  used  more 
than  once  Is  also  futile. 

The  use  of  a  Higher  Order  Language  such  as  Ada  Implies  that  some 
(hopefully  a  small)  amount  of  runtime  efficiency  Is  given  up  In  order  to 
achieve  higher  software  development  and  maintenance  productivity.  In 
embedded,  real-time  applications  It  would  not  be  acceptable  to  give  up 
another  significant  degree  of  efficiency  to  obtain  reusability.  For  this 
reason  the  goal  was  set  that  any  software  part  developed  on  CAMP  must  be  as 
efficient  as  a  custom  written  Ada  component  developed  for  a  particular 
application  by  an  expert  Ada  programmer. 

One  of  the  pitfalls  In  developing  reusable  software  parts  Is  to 
strive  so  hard  for  generality  that  the  part  requires  too  much  Information 
from  the  user  and  Is  therefore  difficult  to  use.  On  CAMP  It  was  established 
that  simplicity  would  not  be  sacrificed  for  power.  Fortunately,  through 
the  appropriate  use  of  defaults  In  Ada  (e.g.,  forcing  Ada  to  look  at  the 
current  context  for  an  overloaded  operator),  the  capability  of  developing  a 
part  which  Is  both  simple  and  powerful  exists.  However,  the  difference 
between  making  a  part  which  Is  simple  or  powerful  and  making  a  part  which  Is 
simple  and  powerful  Is  a  substantial  amount  of  extra  work. 


Another  common  pitfall  In  the  development  of  reusable  parts  Is  to  build 
Into  the  parts  a  bias  towards  one  way  of  solving  a  problem.  CAMP  established 
the  goal  of  multiple  levels  of  part  usage.  This  goal  states  that  If  In 
order  to  meet  future  requirements.  It  Is  envisioned  that  the  operations  or 
objects  that  a  part  provides  can  be  arranged  differently  (but  the 
arrangements  are  unknown  at  the  current  time),  then  the  subparts  of  that  part 
should  be  directly  usable  by  the  end-user  (see  Figure  6). 


Figure  6.  Multiple  Level  Part  Usage 


b.  Automation  Tool  Utility 

The  following  goals  were  set  to  establish  the  utility  of  any 
automated  tool  proposed  In  the  CAMP  project. 

(1)  Automation  tools  should  be  based  on  feasibility  and  value. 

(2)  Automation  tools  should  be  usable  by  the  average  software 
engineer  and  In  some  cases  by  the  domain  engineers  (l.e.  a 

non-software  engineer). 

(3)  The  use  of  esoteric  technologies  should  be  avoided  when  proven 
technologies  can  solve  the  problem  as  efficiently  and  as 

effectively. 

(4)  Automation  tools  should  simplify  the  process  of  using  complex 
Ada  features. 
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CAMP  was  chartered  to  examine  existing  and  emerging  technologies 
which  could  be  used  to  automate  or  semi-automate  the  process  of  developing, 
using,  and  managing  software  parts.  One  of  the  pitfalls  In  this  type  of  work 
Is  to  develop  a  tool  which  while  feasible,  Is  not  practical.  The  goal  was 
set  on  CAMP  that  the  proposed  tool  must  be  capable  of  being  constructed  so 
It  could  be  used  by  the  average  software  engineer  to  perform  actions  which 
needed  to  be  performed  and  perform  these  actions  more  efficiently  and/or 
effectively  than  the  software  engineer  could. 

Researchers  typically  like  to  use  the  newest  gadget  to  solve 
problems.  On  CAMP  it  was  established  that  proven  technologies  would  be  used 
wherever  possible.  For  example,  although  a  software  parts  catalog  could  be 
established  using  an  expert  system.  It  could  also  be  developed  using 
classical  data  base  management  systems.  On  the  other  hand,  when  the 
requirements  are  to  provide  advanced  cataloging  features,  and  Integrate  the 
catalog  with  a  software  generation  system,  an  expert  system  might  be  needed. 

The  fact  that  Ada  Is  a  very  powerful  language  Is  an  advantage  and  a 
disadvantage.  Ada  allows  programmers  to  do  things  which  they  could  not  do 
before,  but  at  the  cost  of  having  to  learn  how  to  properly  use  quite  complex 
Ada  facilities  (e.g.,  tasking,  generics,  etc.).  CAMP  established  the  goal  of 
developing  tools  which  would  allow  average  missile  software  engineers  to 
exploit  the  power  of  Ada's  more  complex  facilities,  without  having  to  master 
all  their  Intricacies. 


6.  ORGANIZATION  OF  THE  REPORT 

Because  of  the  amount  of  material  to  be  covered,  this  report  has  been 
divided  Into  three  volumes.  Vo'ume  I  contains  overview  material  and  details 
on  the  CAMP  commonality  study.  Volume  II  contains  the  detailed  result  of  the 
CAMP  software  parts  composition  system  study.  Volume  III  contains  details  on 
the  Justification  for  the  parts  Identified  In  the  CAMP  study. 

In  addition  to  this  final  technical  report,  a  number  of  other  documents 
were  prepared  during  the  CAMP  program. 
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a.  A  software  requirement  specification  for  the  CAMP  parts. 

b.  A  software  requirement  specification  for  the  Ada  Missile  Parts 

Engineering  Expert  (AMPEE)  system. 

c.  A  top-level  design  document  for  the  CAMP  parts. 

d.  A  top-level  design  document  for  the  AMPEE  system. 

e.  A  draft  detailed  design  document  for  a  representative  sample  of  the 
CAMP  parts. 

These  documents  were  all  prepared  In  accordance  with  the  Defense  System 
Software  Development  Standard  (DOD-STD-2167) .  Since  this  program  Is  one  of 
the  first  to  produce  documents  In  accordance  with  this  new  DOD  standard, 
comments  regarding  Its  use  are  provided  In  Appendix  D. 
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1 .  INTRODUCTION 

The  first  step  In  determining  whether  reusable  missile  software  parts 
were  feasible  was  to  conduct  a  domain  analysis.  A  domain  analysis  Is  an 
Investigation  of  a  specific  application  area  which  seeks  to  Identify  the 
operations,  objects,  and  structures  which  commonly  occur  In  software  systems 
within  this  area.  Note  that  unlike  a  classical  systems  analysis,  a  domain 
analysis  Is  not  limited  to  one  system,  rather.  It  examines  all  systems  of  a 
certain  type--wh1ch  In  the  case  of  the  CAMP  project  are  missile  flight 
software  systems. 

The  concept  of  a  domain  analysis  Is  not  new.  It  Is  the  cornerstone  of 
the  Draco  system  (References  1  and  2)  and  has  been  acknowledged  by  leading 
software  engineers  as  the  most  difficult  part  of  establishing  a  software 
reusability  program.  This  task  has  been  described  by  L.  Belady  of  the  IBM 
Watson  Research  Center  as: 

"...  tediously  studying  complex  and  often  structurally 
obsolete  software  -  not  considered  a  pleasant  or  even 
respectable  activity  today*  (Reference  3). 

It  Is  Important  to  note  that  the  existence  of  commonality  within  the 
missile  flight  software  application  area  could  not  be  taken  for  granted. 
Although  significant  degrees  of  commonality  have  been  found  In  other 
application  areas,  there  was  no  guarantee  that  such  high  levels  of 
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commonality  existed  In  the  realm  of  missile  software.  The  Missile  Systems 
Division  of  the  Raytheon  Company  has  had  a  good  deal  of  success  with  reusing 
software.  However,  the  application  domain  In  which  this  work  was  performed 
was  not  missile  software;  rather,  It  was  business-oriented  Information 
processing  systems  written  In  COBOL.  They  report  (Reference  4)  that  40 
percent  to  60  percent  of  their  programs'  code  was  found  to  be  repeated  in 
more  than  one  application,  and  they  have  standard  software  parts  to  take 
advantage  of  this  fact. 

few  organizations  or  researchers  have  conducted  an  In-depth  domain 
analysis  of  embedded  real-time  software  systems.  The  primary  reason  for  this 
seems  to  be  that  Investigators  were  put  off  both  by  the  complexity  of  the 
software  and  the  application  expertise  required.  For  example,  S.  Sundfor 
(References  5  and  6)  started  to  evaluate  the  applicability  of  Draco  (a 
particular  software  generation  system)  for  real-time  software  systems,  but 
Instead,  ended  up  using  It  on  a  graphic-based  application.  The  point  to  be 
made  here  Is  that  a  domain  analysis  of  embedded  real-time  software  systems 
must  Involve  both  software  engineering  expertise  and  application  domain 
expertise.  The  domain  analysis  for  CAMP  met  these  criteria  because  It 
Involved  knowledgeable  software  engineers  as  well  as  expert  engineers  from 
other  missile  systems  areas  (e.g.,  guidance  and  control,  etc.). 

Domain  analyses  are  not  cheap  to  perform.  They  require  an  Intensive 
examlna  tlon  of  existing  software  systems  within  the  application  area  being 
studied,  and  personnel  skilled  both  In  modern  software  development  techniques 
and  In  the  application  area.  Yet,  to  attempt  to  start  a  software  reusability 
program  without  adequately  performing  this  analysis  Is  as  foolish  as 
attempting  to  design  a  software  system  without  performing  an  analysis  of  the 
software  requirements  (unfortunately  both  these  situations  occur  more  often 
then  we  like  to  think) . 

There  are  three  steps  Involved  In  the  performance  of  a  domain  analysis: 


a. 

The 

Domain  Definition, 

b. 

The 

Domain  Representation,  and 

c . 

The 

Commonality  Study. 
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Each  of  these  activities  are  discussed  In  paragraphs  2  through  4. 
Paragraph  5  discusses  various  classifications  of  parts  and  types  of 
commonality.  Paragraph  6  lists  several  general  observations  made  during  the 
CAMP  domain  analysis.  Paragraph  7  lists  the  parts  Identified  during  the  CAMP 
domain  analysis. 


2.  THE  DOMAIN  DEFINITION 

Domain  definition  Is  the  process  of  determining  the  scope  of  the  domain 
analysis  ( 1 . e . ,  what  application  area  will  be  examined).  Although  this 
appears  to  be  a  straight-forward  task,  there  are  several  factors  which 
Introduce  complexity. 

a.  Fuzzy  domain  boundaries 

b.  Domain  Overlaps 

c.  Domain  Intersections 

Domains  (like  so  many  other  things)  do  not  have  rigid  boundaries.  What 
one  person  might  firmly  believe  to  be  within  a  domain  another  person  would 
not.  It  Is  extremely  Important  that,  early  In  the  domain  analysis,  time  and 
effort  be  expended  to  Identify  these  areas  of  contention  and  that  a  clear 
definition  of  functional  areas  be  defined  for  the  domain  In  question.  In  the 
case  of  CAMP,  the  AFATL  established  a  general  definition  of  the  domain  which 
was  then  refined  by  MDAC-STL. 

The  problem  of  overlapping  domain  has  to  do  with  the  fact  that  some 
functional  areas  within  the  domain  under  examination  (e.g.,  missile  flight 
software  systems)  might  also  be  legitimately  within  another  domain  (e.g., 
avionic  flight  software).  The  presence  of  the  overlap  by  Itself  Is  not  a 
problem  (In  fact.  It  Is  a  benefit  since  the  work  done  for  one  domain  can  be 
applied  at  no  additional  cost  to  the  other  domain).  The  problem  Is  a  matter 
of  losing  sight  of  the  original  domain  (l.e.,  being  sidetracked  Into  the 
overlapped  domain).  The  solution  to  this  problem  Is  to  establish  safeguards 
(e.g.,  periodic  reviews)  which  will  ensure  that  the  domain  analysis  Is 
addressing  Issues  In  the  domain  of  Interest. 
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A  similar  problem  occurs  when  a  functional  area  within  the  domain  under 
examination  applies  to  a  wide  spectrum  of  domains.  Figure  7  depicts  this 
s 1 tuat 1  on . 
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Figure  7.  Vertical  and  Horizontal  Domains 


A  Vertical  Domain  Is  an  application  oriented  grouping  of  software 
systems.  A  Horizontal  Oomaln  Is  an  application-independent  grouping  of 
software.  CAMP  was  a  vertical  domain,  namely  armonlcs  (armament 
electronics),  which  overlapped  with  quite  a  number  of  horizontal  domains 
(e.g.,  signal  processing,  matrix  algebra,  etc.).  The  problem  which  arises  Is 
the  same  as  the  previous  overlap  situation  being  sidetracked.  It  Is  easy  to 
be  seduced  Into  Identifying  software  parts  not  because  they  are  needed  within 
the  domain  under  examination,  but  because  they  are  a  natural  part  within  the 
horizontal  domain.  In  a  situation  where  unlimited  resources  are  available 
for  a  domain  analysis  this  might  not  be  viewed  as  a  problem.  If  It  Is  a 
problem,  the  answer  Is  to  establish  managerial  controls  (e.g.,  reviews). 
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3.  THE  DOMAIN  REPRESENTATION 


Domain  representation  Involves  the  selection  of  a  set  of  applications 
which  will  serve  to  characterize  the  domain  under  Investigation.  In  the 
Ideal  (but  not  too  realistic)  situation,  all  applications  which  were 
classified  as  being  In  the  domain  would  be  In  this  set.  However,  practical 
constraints  on  time  and  effort  and  the  limitation  of  humans  to  deal  with  too 
much  data  demand  a  subset  of  the  universe  of  discourse. 

There  are  several  factors  which  Influence  this  application  selection  process. 

a.  The  availability  of  Information  concerning  the  applications. 

b.  The  quality  of  the  Information. 

c.  The  representativeness  of  the  applications. 

In  the  case  of  software  systems,  the  availability  of  application 
Information  pertains  to  software  documents.  In  other  words,  can  the  domain 
analysts  get  access  to  the  requirements  specifications,  design 
specifications,  and  code  of  the  systems?  In  addition  to  the  availability  of 
these  documents,  their  quality  Is  a  major  Issue.  Many  old  software  systems 
were  not  documented  well.  As  such,  they  are  not  good  candidates  for  the 
domain  application  set  unless  the  people  who  developed  the  system  are  still 
around  and  willing  to  spend  some  time  with  the  domain  analyst. 

It  Is  extremely  Important  that  the  set  of  applications  which  Is  Intended 
to  represent  the  domain  Is  Indeed  representative  of  that  domain.  For 
example.  It  would  not  make  sense  to  select  only  anti-ship  missile 
applications  If  the  domain  Is  all  missiles. 

The  CAMP  contract  required  the  selection  of  ten  missile  software  systems 
for  which  sufficient  documentation  existed  to  perform  the  commonality  study. 
This  set  of  missile  software  systems  also  had  to  cover  at  least  two  of  the 
following  types  of  missiles:  air-to-air,  alr-to-surface,  surface-to-air,  and 
surface-to-surface.  In  addition,  the  set  of  missile  software  systems  had  to 
Include  the  functional  areas  listed  In  Figure  8. 
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Area 


Subarea 


Function 


Navigation 


Guidance 


Control 


Signal  Processing 
Fuzing 

Weapon/Aircraft 
Avionics  Interface 


Optimal  Estimation 

Strapdown  Navigation 
Guidance  Laws 

Autopilot 

Engine  Management 

Antenna  Control 

Spectral  Analysis 

Optical 

Active 

Semi-Active 

Weapon  Initialization 


Covariance  propagation 
Coupled/Uncoupled 
Kalman  filters 
Quaternion  Processing 
Pursuit  Guidance 
Proportional  Guidance 
Optimal  Guidance 
Digital  Filters 
Pulse  Motor  Logic 

Fast  Fourier  Transforms 
Optimized  Time 
Delay 

Inertial  Systems 
Transfer  Alignment 


Figure  8.  The  CAMP  Functional  Areas 


The  set 
In  Figure  9 
Appendix  A. 
used. 


of  missile  software  systems  chosen  by  the  CAMP  project  Is  shown 
These  missile  software  systems  are  described  In  more  detail  In 
References  7  through  29  list  the  software  documentation  that  was 
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(1)  Flight  software  for  the  Medium  Range  Air  to  Surface  Missile  (A6M-109H) 

(?)  Flight  software  for  the  Medium  Range  Air  to  Surface  Missile  (AGM-109L) 

(3)  Unaided  Tactical  Guidance  Project  Strapdown  Inertial  navigation  program 

(4)  Guidance  and  navigation  program  for  the  Midcourse  Guidance  Demonstration 

(5)  Flight  software  for  the  Tomahawk  Land  Attack  Missile  (BGM-109A) 

(6)  Flight  software  for  the  Tomahawk  Anti  Ship  Missile  (BGM-109B) 

(7)  Flight  software  for  the  Tomahawk  Land  Attack  Missile  (BGM-109C) 

(8)  Flight  software  for  the  Tomahawk  Land  Attack  Missile  (BGM-109G) 

(9)  Flight  software  for  the  Harpoon  Missile  (Block  1C) 

(10)  Safeguard  Spartan  missile 

Figure  9.  The  CAMP  Domain  Application  Set 


4.  THE  COMMONALITY  STUDY 

The  commonality  study  Is  the  portion  of  the  domain  analysis  concerned 
with  Identifying  common  operations,  objects,  and  structures  which  are 
candidates  for  construction  as  reusable  software  parts.  This  analysis  Is 
very  similar  to  the  analysis  performed  In  the  construction  of  an  expert 
system.  Both  these  analyses  are  attempts  to  formalize  a  body  of  knowledge. 

In  the  case  of  an  expert  system  the  knowledge  Is  needed  to  construct  an 
artificial  expert.  In  the  case  of  a  reusability  domain  analysis  the 
knowledge  Is  needed  to  distillate  abstract  requirements  from  concrete 
Instances  of  requirements. 

The  raw  data  for  this  analysis  comes  from  software  documents.  This 
Includes  requirements  specifications,  design  specification,  and,  In  the  worst 
case,  code  listings.  On  the  surface  It  would  appear  that  only  requirement 
specifications  would  be  needed.  After  all,  these  specifications  document 
what  the  application  Is  to  do.  While  a  large  number  of  the  software  parts 
are  able  to  be  Identified  from  these  requirements,  the  design  specification 
also  plays  an  Important  role.  In  addition  to  providing  more  details  about 
the  system  (which  Is  useful  In  understanding  the  requirement)  a  significant 
number  of  parts  cannot  be  Identified  from  the  requirements 
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alone  These  type  of  parts  provide  Internal  functions  which  are  not  directly 
mappable  back  to  the  external  requirements  of  the  system.  Code  listings 
usually  are  not  a  useful  data  source  because  of  their  level  of  detail. 
However,  they  frequently  are  needed  to  help  understand  the  requirements  and 
design  specification. 

The  actual  performance  of  the  commonality  study  Is  best  performed  by 
means  of  what  we  call  the  functional  strip  method.  In  this  method,  the 
analyst  examines  a  particular  application  function  across  all  the 
applications  In  the  domain  representation  set.  Tor  example,  the  analyst 
would  Investigate  how  the  strapdown  computations  were  Implemented  In  all  the 
missiles.  The  more  narrow  these  functional  strips  are,  the  easier  It  Is  to 
detect  commonality.  However,  If  the  strips  are  too  narrow,  then  some  higher 
level  commonality  might  be  overlooked.  We  found  In  CAMP  that  data  flow 
modeling  was  a  good  technique  for  representing  the  functions  of  each  of  the 
missiles  In  a  manner  which  would  highlight  their  similarities.  Two  barriers 
which  need  to  be  overcome  In  this  analysis  are  arbitrary  differences  and 
notatlonal  differences. 

In  some  cases,  two  systems  will  perform  an  operation  differently  for  no 
valid  reason.  In  others  words,  they  could  have  used  the  same  operation.  The 
determination  that  an  operational  difference  Is  arbitrary  Is  not  a  conclusion 
which  should  be  reached  casually.  It  Is  very  easy  to  mistakenly  call  a 
difference  arbitrary  because  of  a  lack  of  understanding.  If  the  difference 
Is  really  arbitrary,  one  (or  both)  operations  can  be  candidate  for  parts. 

A  major  problem  with  detecting  commonality  In  embedded  real-time  system 
Is  the  fact  that  different  applications  will  use  different  notation  and/or 
different  algebraic  formulation  for  the  same  operation.  To  the  software 
engineer  not  well  versed  In  the  application  two  names  or  equations  which  are 
almost  the  same  present  a  dilemma  are  they  the  same  or  not. 
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5.  PARTS  CLASSIFICATION 


During  the  CAMP  commonality  study,  It  was  recognized  that  commonality 
existed  at  several  different  levels.  Three  such  levels  are  depicted  In 
Figure  10. 


FUNCTIONAL 

USING  A  PRE  PACKAGED  SERIES 

a  urs  *  pr>  Anrn*Ti/Mir 

ji  Miiwwnu  urcnMiiwixj 


GRAVITY 

COMPUTATION 


GRAVITATIONAL 

ACCELERATION 


PATTERN 

USING  A  REOCCURRING  PATTERN  OF  LOGIC 


ARCHITECTURAL 

USING  A  COMMON  MODEL  OF  A  MULTIPLE 
COMPONENT  SUBSYSTEM 


Figure  10.  Three  Levels  of  Commonality 


Functional  commonality  Involves  a  black  box  view  of  common  operations 
(l.e.,  packing  a  series  of  standards  operations).  This  Is  the  type  of 
commonality  classically  associated  with  software  reusability.  The  equations 
for  computing  gravitational  acceleration  are  an  example  of  functional 
commonality. 
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Pattern  Commonality  Involves  the  recognition  that  there  are  common 
patterns  of  logic  that  recur  time  and  time  again  In  missile  software  systems 
which  are  more  complex  than  simple  black  box  functions.  A  finite  state 
machine  Is  an  example  of  pattern  commonality.  This  pattern  appears  In 
missile  software  systems  In  the  platform  caging  function,  the  launch  platform 
Interface  function,  and  many  other  functional  areas. 

Architectural  Commonality  Involves  the  recognition  that  there  exists 
common  models  of  a  major  component  of  a  missile  software  system.  This  type 
of  commonality  Is  similar  to  pattern  commonality,  except  that  It  Is  on  a 
larger  scale.  A  Strapdown  Navigation  subsystem,  or  a  pitch  autopilot  Is  an 
example  of  architectural  commonality.  At  an  appropriately  high  level  of 
abstraction  there  exists  a  common  model  for  both  of  these  subsystems.  One 
clue  that  architectural  commonality  exists  Is  the  existence  of  standard 
pictures  of  a  process  In  text  books  on  the  subject  In  question. 

The  presence  of  multiple  levels  of  commonality  has  a  major  Impact  on  the 
way  In  which  a  domain  analysis  Is  performed.  If  domain  analysts  look  only 
for  similar  equations  and  operations  at  a  low  level,  they  are  likely  to 
overlook  the  existence  of  commonality  at  the  higher  levels.  For  this  reason, 
the  analysts  must  be  sensitive  not  only  to  the  details  of  the  systems  they 
are  studying,  but  also  to  abstractions  of  which  the  systems  under  examination 
are  Instances. 

During  the  CAMP  domain  analysis  we  recognized  that  two  classes  of  parts 
were  being  1dent1f1ed--doma1n  dependent  parts  and  domain  Independent  parts. 
Domain  dependent  parts  provide  operations  and  objects  which  are  applicable 
only  to  the  domain  being  Investigated  (and  perhaps  to  other  very  closely 
related  area).  In  the  CAMP  domain  analysis,  domain  dependent  parts  are 
applicable  to  missile  software  systems  (In  some  cases  these  parts  could  also 
be  useful  to  the  closely  related  avionics  area).  Domain  Independent  parts 
provide  operations  and  objects  which,  while  highly  relevant  to  the  domain 
under  examination,  are  also  useful  to  other  application  areas.  The  math 
parts  which  were  Identified  during  CAMP  are  examples  of  domain  Independent 
parts.  They  are  needed  In  the  missile  sof-.Uire  domain,  but  they  are  also 
useful  In  other  real-time  embedded  software  systems. 
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Given  the  large  number  of  parts  typically  Identified  during  any  domain 
analysis.  It  Is  often  useful  to  develop  some  type  of  Software  Parts 
Taxonomy.  A  software  parts  taxonomy  Is  a  means  of  classifying  parts  which 
can  help  the  domain  analysts  organize  their  work.  The  taxonomy  developed 
during  CAMP  (which  was  a  very  dynamic  entity)  Is  shown  In  Figure  11. 


camp  parts taxonom y  J|i||||||ii!l||^||||||| 

*  DATA  PACKAGE  PARTS 

•  PROCESS  MANAGEMENT  PARTS 

-  DATA  CONSTANT  PARTS 

-  ASYNCHRONOUS  CONTROL  PARTS 

-  DATA  TYPES  PARTS 

-  COMMUNICATION  PARTS 

•  EQUIPMENT  INTERFACE  PARTS 

•  MATHEMATICAL  PARTS 

-  GENERAL  PURPOSE  EQUIPMENT  INTERFACE  PARTS 

-  COORDINATE  ALGEBRA  PARTS 

-  SPECIFIC  EQUIPMENT  INTERFACE  PARTS 

-  MATRIX  ALGEBRA  PARTS 

-  QUATERNION  ALGEBRA  PARTS 

•  PRIMARY  OPERATION  PARTS 

~  TRIGONOMETRIC  PARTS 

-  NAVIGATION  PARTS 

-  DATA  CONVERSION  PARTS 

-  KALMAN  FILTER  PARTS 

-  SIGNAL  PROCESSING  PARTS 

-  GUIDANCE  6  CONTROL  PARTS 

*  POLYNOMIAL  PARTS 

-  NON-GUIDANCE  CONTROL  PARTS 

-  GENERAL  MATH  PARTS 

•  ABSTRACT  MECHANISM  PARTS 

-  ABSTRACT  DATA  STRUCTURE  PARTS 

-  ABSTRACT  PROCESS  PARTS 

•  GENERAL  UTILITY  PARTS 

Figure  11.  The  CAMP  Software  Parts  Taxonomy 

Appendix  B  describes  the  taxons  (l.e.,  the  Individual  classes)  within 
this  taxonomy. 

Early  In  the  domain  analysis.  It  was  recognized  that  we  were  Identifying 
three  types  of  parts  based  on  how  the  parts  would  need  to  be  constructed  (see 
Figure  12). 
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CAMP  PARTS 

! 


+ - + - + 

I  I 

|  Meta-Parts 

I  I 

|  + - + - + 

I  I  I 

Simple  Parts  Generic  Parts  Schematic  Parts 

as-ls  parts  tallorable  parts  generatable  parts 

Figure  12.  The  Three  Types  of  Software  Parts 


A  Simple  part  Is  a  software  part  which  Is  capable  of  being  reused  as 
Is.  In  other  words,  these  parts  could  be  used  without  any  tailoring  by  the 
user . 

The  Idea  of  a  meta-part  Is  that  sometimes  we  want  a  family  of  parts, 
but  do  not  want  to  build  or  maintain  each  member  of  that  family.  Unlike  a 
simple  part,  meta-parts  cannot  be  used  as  they  exist.  Rather,  they  must  be 
customized  to  a  particular  application.  In  Volume  II  the  use  of  a  software 
generation  system  to  perform  this  customization  will  be  discussed.  Two  types 
of  meta  parts  have  been  Identified;  they  are  distinguished  by  how  a 
particular  member  of  the  family  of  parts  described  by  the  meta-part  Is 
obtained 

A  generic  part  Is  a  template  from  which  a  number  of  specific  parts 
can  be  obtained  by  means  of  the  Ada  generic  facilities.  These  are  parts  In 
which  the  parameterization  of  the  part  conforms  to  the  capabilities  of  an  Ada 
generic  unit.  One  example  of  this  level  of  part  would  be  an  abstract  data 
structure  such  as  a  generalized  First  -  In- F 1 rst -Out  (FIFO)  queue  In  which  the 
type  of  the  data  objects  to  be  queued  would  be  supplied  and  a  specific  flFO 
queue  part  would  be  Instantiated  for  that  situation. 
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A  schematic  part  consists  of  a  template  and  a  set  of  construction  rules 
which  are  used  to  generate  a  number  of  specific  components.  Schematic  parts 
differ  from  generic  parts  In  two  Important  aspects:  (1)  the  generation  of 
specific  parts  from  a  schematic  part  cannot  be  achieved  by  means  of  the  Ada 
generic  facilities;  and  (2)  there  Is  no  code  to  look  at  until  a  specific  part 
Is  built.  A  relatively  simple  example  of  a  schematic  part  would  be  a  finite 
automaton  which  requires  the  association  of  a  actions  with  state  transitions 
(these  types  of  finite  automata  are  usually  referred  to  as  Healy  machines). 
The  requirement  that  actions  be  associated  with  state  changes  cannot  be 
realized  In  Ada  even  with  Its  generic  facilities  because  Ada  does  not  have  a 
variable  procedure  dat3  type.  However,  the  structure  of  such  a  part  Is 
straightforward.  Therefore,  the  schematic  construction  rules  would  be  used 
to  build  an  Ada  unit  which  meets  the  needs  of  the  user. 

The  Idea  of  a  schematic  part  Is  not  a  new  concept  (although  our  use  of 
the  term  schematic  Is  new).  Many  researchers  have  talked  about  standardizing 
software  designs.  Raytheon  (Reference  4)  has  standardized  code  fragments 
which  represent  the  major  logic  structures  within  their  application  area. 
These  code  fragments  serve  as  templates  which  are  reused  between 
applications.  Other  researchers  (References  30,  31,  32,  and  33)  have  also 
recognized  the  benefits  of  reusable  software  designs. 

Our  use  of  the  term  'schematic'  as  opposed  to  'design'  Is  to  Imply  that 
given  the  requirements  of  the  part,  an  expert  programmer  would  know  how  to 
build  the  part,  and  this  knowledge  forms  a  schematic  of  the  family  of  parts. 

A  standard  design,  unlike  a  schematic  part,  does  not  Imply  an  associated  set 
of  construction  rules. 


6.  GENERAL  OBSERVATIONS 

One  of  the  general  goals  of  the  domain  analysis  was  to  Identify  the 
characteristics  of  missile  flight  software  which  distinguish  It  from  other 
software.  These  characteristics  would  then  be  used  to  drive  the  detailed 
analysis  needed  to  Identify  parts  and  meta-parts.  Figure  13  lists  the 
characteristics  Identified  In  this  analysis.  Each  of  the  characteristics  has 
an  effect  on  the  detailed  domain  analysis  as  discussed  In  the  following 
paragraphs . 
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•  Very  high  degree  of  data  flow  Inter  connectivity 

•  Complex  decision  making 

•  Large  number  of  mathematical  data  transformations 

•  Little  data  movement 

•  Relatively  simple  data  structures 

•  External  Interfaces  with  special  purpose  equipment 

•  Processes  that  have  rigid  temporal  relationships 

•  High  use  of  Intermediate  results  of  calculations 

•  Time-Driven  processes 

Figure  13.  Characteristics  of  Missile  Flight  Software  Systems 


Missile  software  systems  tend  to  have  a  large  number  of  Independent  data 
objects  which  must  be  communicated  between  functions.  The  ramification  of 
this  fact  Is  that  the  use  of  non-parameter  procedure  communication  Is 
essential.  As  such,  In  a  system  with  asynchronous  processes,  data  update 
protection  must  be  provided  so  that  If  one  process  Is  updating  a  piece  of 
common  data  It  cannot  be  accessed  by  any  other  process  (either  to  read  or 
write).  This  protection  would  only  be  needed  for  data  objects  which  are 
larger  than  the  unit  (typically  a  word)  which  Is  automatically  protected  by 
the  computer.  Without  this  protection,  the  problem  of  data  Integrity  will 
arise.  The  Impact  of  this  fact  on  the  CAMP  Investigation  was  to  cause  us  to 
design  data  package  parts  and  communication  mechanisms  to  support  this 
behavior . 

Early  In  the  Investigation  we  realized  that  a  large  percentage  of  missile 
functions  are  devoted  to  decision  making  processes  (l.e.,  should  an  action  be 
taken  Iri  light  of  tne  current  situation).  This  caused  us  to  take  a 
macroscopic  view  of  the  missile  functions,  looking  for  recurring  patterns  of 
decision  making.  Ihe  result  of  this  was  the  Identification  of  several 
abstract  processes  which  provide  these  logic  patterns. 

The  fact  that  missile  software  systems  use  a  large  number  of  mathematical 
transformations  is  certainly  not  new,  but,  we  were  driven  by  this  fact  to 
look  for  more  powerful  mathematical  primitives.  Examples  of  these  types  of 
parts  would  be  Interpolation  tables,  change  accumulators,  etc.  While  these 
parts  are  still  quite  primitive,  they  capture  some  of  the  standard 
mathemat 1  cal  operations  frequently  used  within  missile  systems. 
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One  area  which  the  CAMP  team  did  not  have  to  devote  much  time  to  was  the 
process  of  data  movement  (e.g.,  sorts,  ordered  lists,  etc.).  While  some  of 
these  operations  and  structures  were  needed  (e.g.,  the  maintenance  of  mission 
data,  etc.)  they  do  not  play  a  major  role  In  this  type  of  software.  In  a 
similar  vein,  missile  software  does  not  normally  use  complex  data  structures 
such  as  multi-threaded  linked  list,  etc.  which  are  typically  found  In  other 
software  systems. 

Because  of  the  need  for  missile  software  to  Interface  with  a  variety  of 
special  purpose  hardware  peripherals,  we  were  driven  to  examine  the 
possibility  of  developing  standard  Interfaces  for  classes  of  equipment  such 
as  Inertial  sensor  assemblies,  radar  altimeters,  etc. 

One  of  the  surprising  results  of  the  Initial  examination  of  the  CAMP 
missile  set  was  the  realization  that,  to  a  large  degree,  they  did  not  need 
exotic  tasking  capabilities.  We  observed  that  a  large  percentage  of  the 
asynchronous  behavior  of  these  systems  could  be  captured  by  one  level  of 
tasking.  In  other  words,  deeply  embedded  tasking  Is  not  needed.  In 
addition,  these  tasks  fell  neatly  Into  one  of  a  small  number  of  categories. 

a.  Aperiodic  processes 

b.  Continuous  processes 

c.  Periodic  processes 

d.  Data-driven  processes 

e.  Interrupt-driven  processes 

Because  of  this  observation  we  were  driven  to  look  at  a  way  to 
standardize  the  construction  of  the  asynchronous  structure  of  missile 
software  systems.  The  result  of  this  was  the  development  of  process 
controller  part  and  the  task  shell  parts. 

A  very  Important  observation  from  the  Initial  Investigation  was  that 
missile  software  systems  make  heavy  use  of  Intermediate  results.  For 
example,  In  the  area  of  the  primary  navigation  functions,  not  only  are  the 
end  results  such  as  velocity  and  position  needed,  but  the  results  of 
Intermediate  calculations  used  to  achieve  those  results  are  needed  by  other 
functions  such  as  the  Kalman  filter.  The  major  Impact  of  this  observation 
was  to  cause  us  to  design  the  parts  so  that  the  parts'  Intermediate  results 


29 


were  kept  In  a  separate  package  from  the  calculat Ions ,  see  figure  14.  In 
this  fashion,  the  Intermediate  results  are  available  both  to  the  function 
which  calculated  them  and  to  other  functions. 
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figure  14.  The  External  Packaging  of  Oata 

The  final  observation  from  the  Initial  analysis  was  that  there  were  many 
actions  which  were  time-driven.  As  such  we  looked  for  standard  parts  to 
capture  the  pattern  of  these  paradigms.  The  result  was  the  domain 
Independent  process  sequencers. 


7.  PARTS  IDENTIFICATION 

Over  200  parts  were  Identified  during  the  CAMP  domain  analysis.  Appendix 
C  lists  these  parts  which  are  discussed  In  much  greater  detail  In  the  Parts 
Software  Requirements  Specification  for  CAMP  and  In  Volume  III  of  this  report. 

One  of  the  difficulties  we  encountered  during  the  domain  analysis  and 
later  In  the  design  phase  of  CAMP,  was  what  to  call  a  part,  for  example.  In 
an  Ada  package  which  provides  a  large  number  of  subprograms  which  are  related 
(but  do  not  have  Information  strength)  are  the  Individual  exported 
subprograms  each  called  a  part  Likewise,  Is  a  schematic  part  (which  unlike 
a  generic  part  doesn't  exist  as  Ada  code  until  after  a  specific  Instance  Is 
generated)  a  part?  During  CAMP  we  used  common  sense  to  guide  us  In 
delineating  what  were  parts  and  what  were  not.  No  definitive  procedure  was 
established . 
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SECTION  III 
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1 .  INTRODUCTION 

The  specification  of  CAMP  parts  must  address  a  number  of  different 
aspects  of  reusable  software.  The  specification  must  Inform  the  part  user  of 
what  the  part  accomplishes  functionally  and  also  provide  performance 
Information  about  the  part.  The  specifications  must  be  documented  In 
accordance  with  the  Software  Requirements  Specification  (SRS)  OID  of 
000- STD-2167,  and  must  facilitate  communication  of  the  part's 
characteristics.  A  final  requirement  of  the  specification  Is  to  provide  an 
environment  for  the  part,  describing  the  dependencies  which  exist  between 
parts. 

The  CAMP  specification  technique  utilizes  both  textual  and  graphical 
documentation  In  accomplishing  these  goals.  The  textual  form  Is  based  on  the 
SRS  and  provides  a  verbal  description  of  the  requirements  for  each  part, 
following  the  Input-processing-output  format.  The  graphical  form  provides 
data  flow  Information  about  each  part  and  serves  as  a  mechanism  for 
communicating  part  requirements  to  missile  system  engineers.  This  section 
will  present  the  specification  technique  and  will  document  the  rationale 
behind  It. 

2.  ISSUES 

The  specification  of  requirements  for  reusable  software  necessitates  a 
different  approach  from  that  used  for  single-user  software.  The  Defense 
System  Software  Development  Standard  (D0D-ST0-2167)  establishes  the  concept 
of  a  Computer  System  Configuration  Item  (CSCI)  as  the  basis  for  software 
development  and  defines  a  CSCI  as  Implementing  a  complete  software 
subsystem.  The  standard  specifies  that  requirements  shall  be  derived  from 
the  system  requirements  as  defined  In  the  system/segment  specification  for 
each  CSCI  and  shall  be  documented  In  a  Software  Requirements  Specification. 
This  Specification  shall  provide  Interface  and  data  requirements  for  the  CSCI 
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plus  detailed  functional  and  performance  requirements  for  each  functional  or 
structural  component  within  the  CSCI. 

There  are  three  main  Issues  surrounding  the  specification  of  parts  within 
the  CAMP  domain:  what  constitutes  a  part,  how  the  part  will  be  used,  and  how 
to  specify  a  part  so  that  It  Is  reusable.  The  first  Issue  will  emerge  from 
the  process  of  decomposing  system  specifications  Into  parts.  The  second 
Issue  will  emerge  from  creating  Ada  design  methods.  The  third  Issue  will 
depend  on  the  choice  of  a  specification  technique.  These  three  Issues  are 
discussed  below. 

The  decomposition  of  the  CAMP  CSCI  Into  software  requirements  Is  a  major 
Issue  of  the  CAMP  study.  For  CAMP  parts,  the  CSCI  consists  of  the 
requirements  derived  from  the  Commonality  Study.  In  essence,  CAMP  will  be 
developing  a  CSCI  to  meet  the  system  requirements  of  the  entire  missile 
group,  and  It  Is  this  missile  group  which  constitutes  the  system/segment. 

This  CSCI  will  not  meet  the  entire  software  requirements  of  any  one  missile 
and  will  not  Implement  a  complete  software  subsystem.  Rather,  the  CAMP  CSCI 
must  provide  parts  which  meet  requirements  which  are  common  to  a  number  of 
missiles  In  the  group.  Together  with  custom  software,  the  parts  will  provide 
the  capability  of  Implementing  a  software  subsystem. 

A  second  Issue  Is  the  development  of  requirements  which  must  not  only 
establish  the  functional  nature  of  the  nart,  but  must  also  establish  a  means 
of  using  the  part.  Ihe  functional  nature  of  a  part  can  be  derived  from  the 
domain  analysis,  l.e.,  the  requirement  of  a  reusable  part  will  be  based  on 
requirements  for  specific  missile  functions.  But  use  of  a  part  must  take 
Into  account:  Incorporating  the  part  Into  a  design  which  Is  utilizing 
reusable  software,  and  making  use  of  other  reusable  parts  In  order  to  remain 
consistent  with  the  rest  of  the  CSCI. 

While  these  Issues  would  generally  be  considered  design  considerations 
for  single  use  software,  they  play  an  Important  role  In  establishing  the 
requirements  for  reusable  parts.  In  fact,  the  data  constant  and  data  type 
parts  exist  solely  to  support  the  design  of  functional  parts  which  can  serve 
as  part  of  a  larger  design 

The  requirements  for  single  use  software  establish  a  single,  complete 
software  subsystem.  The  definition  of  this  unique  subsystem  will  provide  the 
softwa  e  Interfaces  to  other  software  components  as  well  as  to  hardware 
components.  The  functional  and  performance  requirements  of  the  entire  system 
will  form  the  basis  for  choosing  these  Interface  requirements. 
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The  specification  of  reusable  software  parts  must  allow  for  their 
Integration  Into  a  variety  of  different  contexts.  This  need  arises  because 
reusable  parts  must  address  a  wide  range  of  system  requirements,  rather  than 
requirements  of  a  single  system,  and  must  facilitate  composition  Into  larger 
software  entitles.  While  Inputs  to  and  outputs  from  a  given  function  will 
form  the  basis  of  Interfaces  to  a  part,  the  requirements  must  also  address 
the  problem  of  Integrating  lower  level  functions  Into  higher  level  operations 
or  subsystems. 

Because  the  CAMP  parts  must  be  specified  to  meet  requirements  of  an  11th 
missile,  (l.e.,  a  missile  that  was  not  used  In  the  commonality  study),  the 
final  Issue  Is  specifying  parts  which  can  be  composed  Into  systems  which  have 
not  yet  been  defined.  The  Interfaces  between  the  larger  entitles  which  go 
Into  this  new  missile  must  also  be  considered  at  the  time  the  parts  are 
specified.  For  this  reason,  the  CAMP  specifications  must  Identify  parts 
which  are  capable  of  Integration  Into  more  complex  functions,  and  which  are 
flexible  In  their  application. 

3.  THE  SOFTWARE  REQUIREMENTS  SPECIFICATION 

The  CAMP  program  effectively  applied  the  new  000  standards  for  the 
specification  of  CAMP  parts.  The  program  developed  a  Software  Requirements 
Specification  following  the  tasks  described  under  section  5.1  of 
D0D-  STD- 21 67 .  The  Specif  1c«  L'on  Is  In  accordance  with  01  -MCCR-80025, 

Software  Requirements  Specification.  The  structure  of  the  DIO  requires  some 
tailoring  to  address  the  Issues  discussed  above.  The  remainder  of  this 
section  summarizes  the  changes  made  by  the  CAMP  group  to  tailor  the  OID  for 
the  description  of  reusable  software  parts. 

The  new  standard  Is  especially  effective  In  clearly  separating  the 
requirements  and  design  activities  Into  three  distinct  areas:  (1)  software 
requirements  analysis,  (2)  preliminary  design,  and  (3)  detailed  design. 
Previous  standards  such  as  DOD-STD  1679  and  MIL-STD-483  do  not  make  this 
distinction  and  preliminary  design  Is  subsumed  under  requirements  analysis 
and  detailed  design.  This  clear  delineation  also  lends  Itself  to 
establishing  the  manner  In  which  Ada  should  be  applied  to  the  documentation 
process,  as  Is  discussed  below. 
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a.  The  Use  of  Ada  In  the  Specifications 


The  CAMP  development  effort  demonstrated  that  the  SRS  should  be 
prepared  without  reference  to  a  specific  Ada  architecture.  While  other 
studies  have  attempted  to  use  Ada  as  a  software  requirements  language,  the 
CAMP  approach  yielded  more  generalized  requirements  specifications,  essential 
for  developing  reusable  Ada  software.  The  development  of  the  requirements 
must,  of  course,  take  cognizance  of  Ada,  to  assure  that  the  capabilities  of 
Ada  are  fully  exploited  and  to  establish  requirements  which  are  conducive  to 
Ada  Implementation,  furthermore,  Ada  terminology  (e.g.,  tasks,  packages, 
generics)  Is  applied  wherever  appropriate.  Nonetheless,  keeping  the 
requirements  free  of  Ada  constructs  Improved  the  readability  and  utility  of 
the  parts  specifications. 

In  addition  to  documenting  specifications,  the  SRS  also  establishes 
design  guidelines.  The  distinction  between  requirements  and  design  allows 
CAMP  to  create  an  architectural  design  based  on  Ada  packages.  The  top-level, 
or  architectural,  design  defines  these  packages,  their  Interfaces,  and  major 
architectural  Issues  In  the  design  of  the  package  bodies.  The  lower-level, 
or  detailed,  design  shows  the  algorithmic  design  for  subprograms  defined  in 
the  top  level  design  and  also  defines  the  suoprogram  and  data  structures 
which  are  encapsulated  within  the  common  package  bodies.  These  design  Issues 
are  fully  discussed  In  Section  IV. 

b.  The  CAMP  Graphical  Technique 

The  CAMP  Graphical  Technique  offers  a  powerful  yet  simple  means  of 
communicating  the  requirements  and  data  flow  of  CAMP  parts.  Figure  15  shows 
the  data  flow  of  a  typical  Ada  part.  There  are  three  major  components  to 
these  diagrams: 

(1)  the  rounded  rec^anql.-s  represent  functions  which  the  part  must 

provide 

(2)  the  rectangles  represent  data  stores,  and 

(3)  the  arcs  represent  data  flows. 


Hlf* 


Figure  15.  Data  Flow  of  a  Typical  Part 


This  graphic  technique  also  captures  the  flavor  of  Ada 
specifications,  without  establishing  a  specific  Ada  architecture.  Thus,  the 
functions  can  be  Implemented  as  Ada  procedures  or  functions;  the  data  flows 
can  be  accomplished  through  parameter  passing  or  through  shared  data;  and  the 
data  stores  can  be  Implemented  as  data  structures  In  Ada. 

c.  The  Input-Processing-Output  Description 

The  Input,  processing,  and  output  sections  document  the  processing 
which  must  be  accomplished  by  the  functions  of  a  part.  The  requirements 
specification  must  define  Inputs  to  the  part,  as  Illustrated  In  the  data 
flows,  and  their  data  type  and  meaning.  The  requirements  do  not,  In  general, 
establish  precise  Ada  data  types  and  they  do  not  define  the  data  control, 
l.e.,  parameter  data,  common  data,  or  local  data.  This  precision  Is  supplied 
In  the  design. 
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7 he  SRS  does  establish  the  data  type  In  a  form  easily  recognized  by 
domain  experts.  This  generic  definition  Is  well  suited  to  parts  which  are  to 
be  designed  as  generic  Ada  parts,  where  the  actual  data  type  will  be  assigned 
by  the  part  user  In  those  cases  where  a  precise  data  type  Is  specified  In 
the  requirements,  an  Ada  generic  would  not  be  suitable  for  the  design. 

Ada  operations  are  used  as  a  PDL  In  defining  the  processing  requirements 
of  a  part.  While  this  PDL  definition  Is  not  a  complete  algorithmic 
description  In  most  cases,  It  does  show  the  logical  and  arithmetic  operations 
which  a  part  will  accomplish.  The  exact  nature  of  these  operations  will  be 
derived  from  the  domain  analysis. 

The  definition  of  output  from  a  part  will  be  similar  to  that  of  Input. 

The  data  flows  show  the  output  but  do  not  define  the  data  structures.  The 
part  specification  defines  the  outputs  but  does  not  establish  data  structures 
or  control.  The  design  of  the  part  will  define  these  features. 

d.  The  Environment  Description 

The  CAMP  parts  are  not  Intended  for  stand-alone  use.  They  must  be 
combined  Into  larger  contexts  for  effective  utilization.  Examples  of  this 
combining  of  parts  Is  the  specification  of  requirements  for  Basic  Data  Types, 
and  for  Earth  Constants.  Neither  of  these  packages  Is  useful  by  itself,  but 
they  are  essential  for  the  design  of  other  higher- level  parts.  Another 
example.  Illustrated  In  Figure  16,  Is  the  grouping  of  packages  Into  a  Wander 
Angle  or  North  Pointing  navigation  system. 

However,  the  specific  requirements  for  a  part  cannot  assume  the  existence 
of  the  lower  level  packages.  A  user  may  wish  to  use  the  CAMP  navigation 
packages,  but  riot  want  to  use  the  CAMP  data  types.  The  statement  of  a  part 
environment  will  establish  the  context  of  a  given  part.  Independent  of  other 
CAMP  parts.  Jhe  environment  may  Include  a  description  of  constants  or  of 
data  types  which  are  required  by  a  part.  For  those  parts  requiring  special 
processing,  the  environment  may  Indicate  external  subprograms  which  must 
exist  for  the  part  to  function.  Finally,  the  environment  may  establish  the 
data  which  must  be  supplied  for  Initialization  of  the  state  of  a  given  part, 
Indicating  that  the  part  may  be  designed  as  a  generic. 
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Figure  16.  Creating  an  Environment 
Through  Combining  Parts 
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1.  INTRODUCTION 


A  design  methodology  for  reusable  parts  must  address  several  problems 
arising  from  conflicting  design  requirements.  To  be  reusable,  parts  must 
have  well-defined  Interfaces  reflecting  user  requirements.  The  data  types 
used  to  define  these  Interfaces  must  be  strongly  typed  to  minimize 
Inappropriate  use  of  a  part  (e.g.,  using  an  object  of  a  velocity  type  for  a 
parameter  which  should  be  of  a  distance  type).  The  design  methodology  must 
support  the  creation  of  parts  which  provide  a  large  variety  of  arithmetic, 
trigonometric,  matrix  and  ether  mathematical  functions  capable  of  operating 
on  strongly  typed  data.  Finally,  the  method  chosen  must  ease  the  Job  of  a 
part  user,  possibly  at  the  expense  of  a  significant  Increase  In  the 
development  costs  of  the  part.  These  design  requirements  (summarized  In 
Figure  17)  are  necessary  to  provide  parts  which  are  powerful  In 
functionality,  yet  easy  to  use. 

The  CAMP  program  has  produced  a  top-level  design  methodology  for  parts 
which  can  meet  user  typing  requirements  and  which  can  support  parts  which  are 
well  tested  and  may  be  used  off-the-shelf.  The  methodology  utilizes 


®  Reusable  parts  must  have  well  defined 
^nter f aces . 

*  Data  must  be  strongly  typed  to  minimize 
Inappropriate  use  of  a  part.. 

*  Design  must,  produce  parts  which  provide 
a  variety  of  mathematical  operations  on 
different  data  types. 

*  Design  must  ease  the  Job  of  the  user, 
providing  simple  yet  flexible  parts. 

Figure  n  Issues  Affecting  the  Design  of  Reusable  Parts 


several  of  Ada's  special  programming  features,  Including  derived  types  and 
subprograms,  generic  Instantiation  and  subprogram  overloading.  The  CAMP  team 
believes  that  this  design  approach  will  be  equally  appropriate  for 
non-missile  applications  outside  of  the  CAMP  domain. 

2.  METHODS 

The  CAMP  program  has  considered  six  design  methods  which  attempt  to 
resolve  these  design  conflicts  and  achieve  reusable  parts.  These  methods  are 
called:  Typeless,  Overloaded,  Generic,  State  Machine,  Abstract  Data  Type,  and 
Skeletal.  They  are  Illustrated  In  Figure  18. 

The  processing  required  to  perform  the  Compute  Earth  Relative  Horizontal 
Velocities  function  (SRS  R001)  will  serve  as  an  example  In  applying  these 
methods.  The  Inputs  to  this  computation  are: 


Nominal  East  Velocity  (VEL^) 

Nominal  North  Velocity  (VEl^) 

Wander  Angle  (WA) 

The  function  performs  the  following  operations: 

VELe  :*  VELne  *  cos  (WA)  -  VEL^  *  sin  (WA) 

VEL  :*  VEL  *  sin  (WA)  -  VEL  *  cos  (WA) 

N  Nt  NN 

where 

VELe  Is  velocity  In  the  true  east  direction 

VEL  Is  velocity  In  the  true  north  direction 
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Figure  18.  Design  Methods  for  Reusable  Parts 


a.  Type  less  Method 

The  Tyoeless  method  assumes  that  all  data  objects  and  actual 
parameters  will  be  of  type  float.  The  benefit  of  this  approach  Is  that  It 
alleviates  the  need  for  special  mathematical  operators  and  functions,  since 
they  are  ali  defined  for  float  In  standard  packages.  The  severe  disadvantage 
of  this  method  is  that  the  compiler  and  runtime  system  cannot  perform  type 
checking  to  prevent  misuse  of  a  part,  because  all  objects  are  of  the  same 
type. 

Ihe  recent  failure  of  a  laser  fracking  experiment  on  the  Space 
Shuttle  Illustrates  an  error  which  occurred  from  mixing  data  types.  The 
failure  was  caused  by  entering  data  for  transmitter  elevation  In  units  of 
feet,  while  the  Shuttle's  computer  expected  It  In  nautical  miles.  A  data 

type  and  object  declared  as  follows; 

type  GroundJ:  levatlon  Is  new  Nautical  Miles 
range  -1.0  . .  6.0; 

Transmitter  Elevation:  Ground_Elevat1on; 
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would  solve  the  problem  by  restricting  the  Input  of  Transm1tter_Elevat1on  to 
values  which  are  allowed  by  the  data  type.  Without  this  restriction,  any 
value  would  be  allowable  for  a  ground  elevation,  even  9994  nautical  miles,  as 
was  Input  for  the  experiment  which  failed. 

The  Typeless  method  will  result  In  a  procedure  specification  for  the 
Compute  Earth  Relative  Horizontal  Velocities  as  shown  In  Figure  19.  The 
program  using  this  procedure  could  pass  any  objects  of  the  type  float  as 
actual  parameters.  The  compiler  could  not  perform  type  checking  to  prevent 
type  mismatching  and  there  could  be  no  runtime  checking  to  assure  correct 
ranges  for  the  actual  parameters.  This  method  produces  a  simple  part  design, 
but  because  there  Is  no  error  checking  It  Is  not  a  robust  design. 

function  Compute_Earth_Relat1  ve_Hor1zontal_Veloc1t1es 
(Nom1nal_East_Veloc1ty, 

Nomina l_North_Veloc1ty, 

Wander_Angle_  :  In  float; 

East_Veloc1ty, 

North_Veloc1ty  out  float); 

Figure  19.  Specification  of  a  Function 
Using  the  Typeless  Method 


b.  Overloaded  Method 

The  Overloaded  method  provides  the  user  a  separate  version  of  each 
part  to  allow  for  the  different  combination  of  data  types  which  the  part  user 
might  require.  Figure  20  Illustrates  the  application  of  the  overloaded 
method  to  the  Compute  Earth  Relative  Horizontal  Velocities  where  the 
velocities  are  of  data  types  Feet_Per_Second  and  Meters_Per_Second  and  the 
wander  angle  Is  In  Radians.  Other  overloaded  subprograms  would  allow  wander 
angle  In  degrees  and  semicircles.  This  method  Is  the  same  as  that  used  by 
Ada  packages  such  as  Standard  and  Calendar  to  provide  operations  on  their 
data  types. 

The  major  advantage  of  the  overloaded  method  Is  the  simplicity  It 
offers  In  designing  and  using  the  parts.  The  design..1  will  decide  what 
combinations  of  data  types  will  be  allowed  for  each  part.  He  will  explicitly 
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declare  the  parameter  Interfaces  for  these  overloaded  subprograms  and  can 
design  all  of  the  mathematical  parts  which  the  subprograms  will  use.  In  the 
example  In  Figure  20,  the  mathematical  parts  which  he  must  provide  are  sine 
and  cosine  of  radians,  and  multiplication  of  velocity  by  a  trigonometric 
ratio  returning  a  velocity.  Strict  type  checking  will  assure  that  actual  and 
formal  parameters  match  and  that  the  values  of  the  actual  parameters  fall 
within  ranges  allowed  by  the  type. 

Because  Ada  supports  this  overloading  of  subprogram  definitions,  the 
user  need  not  call  a  version  of  a  part  specific  to  a  given  combination  of  data 

package  Overloaded_Method  Is 

function  Compute_Earth_Relat1ve_Hor1zontal_Veloc1t1es 

(Nom1nal_East_Veloc1ty, 

Nom1nal_North_Veloc1ty :  In  Feet_Per_Second; 

Wander_Angle_  :  In  Radians; 

East_Veloc1ty, 

North_Veloc1ty  :  out  Feet_Per_Second) ; 

function  Compute_Earth_Relat1ve_Hor1zontal Velocities 

(Nom1nal_East_Vel°c1ty , 

Nomlnal-NorthVelocIty:  peet_P®r_S®cond; 

Wander_An9le_  :  In  Radians; 

East_Vel°c^1:y, 

Northjtelodty  :  out  Feet_Per_Second) . 

--  other  overloaded  functions 
end  Overloaded_Method; 

Figure  20.  Specification  of  a  Package 
Using  the  Overloaded  Method 

types;  the  Ada  disambiguation  feature  will  resolve  the  call.  In  fact,  should 
user  requirements  change,  and  a  different  combination  of  data  types  result, 
the  call  need  not  be  changed,  the  Ada  language  will  resolve  the  new  reference. 

The  major  disadvantage  of  this  method  Is  the  large  number  of  parts 
which  must  be  declared  at  the  architectural  level.  In  the  example  cited 
above,  the  Compute  Earth  Relative  Horizontal  Velocities  function  would 
require  six  subprograms  to  accommodate  the  different  data  types.  The  complete 
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navigation  packages  encapsulating  these  overloaded  subprograms  could  grow  to 
100  or  more  subprograms. 

c.  Generic  Method 

The  Generic  method  uses  Ada  generics  to  provide  parts  which  are 
tallorable  to  user-defined  types.  Figure  21  shows  the  generic  Earth 

generic 

type  Velocity  Is  digits  <>; 
type  Wander_Angle  Is  digits  <>; 
with  function  **■ 

(Left : Velocity;  Right:  Tr1g.Tr1g_Value) 
return  Velocity  Is  <>; 
with  function  sin  (Angle:  Wander_Angle) 
return  Tr1g.Tr1g_Value  Is  <>; 
with  function  cos  (Angle:  Wander_Angle) 
return  Tr1g.Tr1g_Value  Is  <>; 
function  Compute_Earth_Relat1ve_Hor1zontal_Veloc1t1es 
(Nom1nal_East_Veloc1ty, 

Nom1nal_North_Veloc1ty:  In  Velocity; 

Wander_Angle_  In  Wander_Angle; 

East_Veloc1ty, 

North_Veloc1ty  :  out  Velocity); 

Figure  21.  Function  Specification  Using  the  Generic  Method 

Relative  Horizontal  Velocities  using  generic  types  for  velocity  and  wander 
angle.  The  specific  types  required  by  an  application  would  be  supplied  when 
the  generic  function  Is  Instantiated. 

The  Ada  generic  facility  allows  functions  and  operators  to  be  passed 
as  parameters.  These  generic  subprogram  parameters  are  used  within 
Individual  parts  to  specify  mathematical  functions  which  are  needed  for 
generic  data  types.  For  example,  the  Compute  Earth  Relative  Horizontal 
Velocities  generic  will  require  sine  and  cosine  functions  on  the  generic 
wander  angle,  and  multiplication  between  the  generic  velocity  and  a 
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trigonometric  ratio.  This  large  number  of  generic  parameters  could  place  an 
enormous  burden  on  the  part  user,  requiring  him  to  specify  all  of  the  actual 
generic  parameters  (both  types  and  subprograms)  needed  by  the  Instantiation. 
In  addition,  he  Is  required  to  create  functions  for  the  actual  generic 
subprogram  parameters.  The  generic  function  which  Is  Illustrated  will 
require  a  total  of  five  actual  generic  parameters  and  for  each  combination  of 
data  types,  the  creation  of  three  functions. 

A  method  which  uses  default  parameters  could  alleviate  some  of  the 
user's  problems.  If  the  design  provides  functions  for  typical  combinations 
of  data  types,  then  the  Instantiation  will,  by  default,  use  these  functions 
as  actual  subprogram  parameters.  Using  the  same  example,  the  design  could 
support  trigonometric  functions  on  radians,  then  If  radians  Is  used  for  the 
angle  generic,  the  Instantiation  would  default  to  these  predefined 
trigonometric  functions  for  the  generic  sine  and  cosine  operations.  The  main 
advantage  of  this  method  Is  to  permit  the  user  great  flexibility  In  the  use 
of  data  types,  yet  provide  a  simple  method  for  using  the  parts. 

d.  State  Machine  Method 

A  state  machine  Is  an  object  consisting  of  data  and  operations  which 
may  be  performed  to  change  the  state  of  that  data.  The  unique  feature  of  a 
state  machine  Is  the  fact  that  the  structure  of  the  data  Is  not  known  outside 
of  the  machine.  The  ability  to  maintain  a  single  set  of  external  Interfaces, 
while  changing  the  Internal  structure  of  the  state  data  Is  a  powerful  feature 
of  this  method.  Because  data  structures  are  not  available  externally,  there 
are  also  operations  which  permit  a  user  of  the  state  machine  to  examine  the 
current  state  of  the  machine  by  retrieving  the  values  of  data.  This 
definition  of  a  state  machine  Is  similar  to  a  black  box  with  procedures  to 
change  the  state,  and  functions  to  read  the  state,  but  no  ability  to  see 
Inside  the  box. 

The  State  Machine  Implementation  of  a  navigation  system  would 
provide  all  of  the  operations  needed  to  perform  the  navigation  functions  plus 
operations  to  obtain  the  value  of  those  data  which  define  the  navigation 
model.  Figure  22  Illustrates  part  of  a  state  machine  Implementation  of  a 
navigation  system. 
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This  approach  would  alleviate  the  data  typing  and  mathematical 
problems  of  the  other  methods,  because  the  part  designer  has  chosen  all 
Internal  data  types  and  defined  the  required  mathematical  operations.  The 
user  of  the  part  would  not  be  able  to  access  any  data  values  stored  within 
the  navigation  model  as  shown  In  Figure  22  except  through  the  Interfaces 
provided  by  the  designer.  However,  there  would  be  unacceptable 
Inefficiencies  In  this  approach,  with  the  need  to  convert  all  data  to  the 
part's  Internal  format. 

with  Bas1c_Data_Types; 
generic 

type  Velocity  Is  digits  <>; 
type  Altitude  Is  range  <>; 
package  Nav1gat1on_State_Mach1ne  Is 

procedure  Compute_Earth_Relat1  ve_Hor1zontal_Veloc1tles; 
procedure  Update_Alt1tude; 

--  Operations  to  provide  state  Information 
function  Current_Alt1tude  return  Altitude; 
end  Nav1gat1on_State„Mach1ne; 

Figure  22.  Package  Specification 

Using  the  State  Machine  Method 

For  example,  the  abstract  data  type  may  assume  that  all  angular  measurements 
are  In  radians.  If  the  user  system  measures  In  degrees,  all  such 
measurements  would  require  conversion  before  use  by  the  abstract  data  type. 
The  part  would  Include  the  routines  to  convert  to  and  from  the  Internal  form, 
but  this  requirement  would  add  an  additional  subprogram  call  to  each 
operation. 

An  additional  advantage  to  this  method  Is  the  ability  to  create  more 
than  one  body  for  a  single  specification.  Because  all  data  Is  controlled 
within  the  body,  a  part  user  may  use  only  the  specification  and  write  his  own 
body,  defining  data  according  to  his  own  choices.  Similarly,  the  parts 
designer  may  provide  multiple  bodies  for  a  single  specification,  thus 
alleviating  the  efficiency  Issues  by  creating  bodies  which  are  efficient  for 
a  particular  situation.  This,  of  course.  Increases  the  cost  of  creating 
parts  and  produces  a  design  with  less  use  of  commonality,  yet  It  Is  an 
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effective  method  when  the  choice  of  a  data  structure  cannot,  for  reasons  of 
efficiency  or  simplicity,  be  established  In  the  package  specification.  This 
method  would  be  appropriate  for  Kalman  Filter  operations,  where  the 
operations  are  well  defined,  but  the  structure  of  the  data  and  the  specific 
operations  on  that  data  will  vary  from  application  to  application. 

e.  Abstract  Data  Type  Method 

The  abstract  data  type  method  can  establish  a  single  data  structure 
at  specification  time  and  thus  Is  completely  reusable  between  applications. 

An  Ada  package  defines  this  abstract  data  type,  providing  a  type  declaration 
plus  allowable  operations  on  the  type.  An  abstract  data  type  differs  from 
other  data  types  In  that  the  Ada  package  hides  details  about  the  structure  of 
the  type.  The  word  hides  describes  the  fact  that  the  data  structure  Is 
controlled  by  the  package;  the  user  of  the  package  knows  the  structure  of  the 
data,  and  may  make  design  choices  based  on  that  structure,  but  he  cannot 
access  data  directly  from  the  structure. 

Information  hiding  of  this  type  Is  accomplished  through  the  Ada 
packaging  construct  which  restricts  access  to  objects  of  the  abstract  type  to 
only  those  operations  defined  by  the  package  specification.  In  contrast  to 
the  Abstract  State  Machine,  the  data  structure  of  an  abstract  data  type  Is 
part  of  the  specification,  and  a  package  body  must  operate  on  that  unique 
structure.  If  a  part  user  wishes  to  use  the  operations  of  the  Abstract  Oata 
Type  but  use  a  different  data  structure,  then  he  must  not  only  rewrite  the 
body  which  will  operate  on  the  data  structure,  but  he  must  also  rewrite  the 
specification  which  defines  the  structure.  This  method  Is  useful  for  such 
data  abstractions  as  vectors  and  matrices,  stacks  and  queues,  but  Is  not 
appropriate  for  more  complex  data  structures  such  as  those  used  by  a 
navigation  system  or  Kalman  Filter  operation. 

The  Ada  design  of  a  typical  abstract  data  type  package  Is  shown  In 
Figure  23.  Note  that  this  example  shows  a  queue  type  as  an  entity  exported 
by  the  package.  The  private  part  of  the  package  will  define  the  Internal 
structure  of  this  type.  A  user  of  the  part  can  then  decide  If  this  structure 
Is  suited  for  his  application.  For  example,  If  the  queue  Is  structured  as  a 
linked  list,  then  the  efficiency  of  dynamic  allocation  of  data  and  access  of 
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data  will  be  design  Issues  which  the  part  user  must  consider.  Had  this 
package  been  defined  as  an  abstract  state  machine,  the  user  would  have  no 
Information  from  the  specification  about  the  nature  of  the  data  structure. 

generic 

type  Queue_Element  Is  private; 

Queue_S1ze:  natural; 
package  Abstract_Queue  Is 

type  Queue  Is  private; 

--  User  of  this  package  will  manipulate  objects  of  the 
--  Queue  type  through  the  following  operations 
procedure  Add  (Element:  In  Queue_Element; 

To_Queue:  In  out  Queue); 

--  Other  operations  .  .  . 
private 

type  Queue  Is  .  .  . 
end  Abstract_Queue; 

Figure  23.  Package  Specification  of  an  Abstract  Data  Type 

To  further  contrast  this  method  with  the  state  machine  approach,  an 
Ada  package  can  define  an  abstract  navigation  data  type,  supported  by  the 
generic  and  private  type  facilities  of  Ada.  This  package  would  define  a 
navigation  type  and  all  the  operations  needed  to  perform  the  navigation 
functions.  The  details  of  Implementation  of  this  type  would  be  given  In  the 
private  part  of  the  package.  This  method  Is  Illustrated  In  Figure  24. 
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with  Bas1c_Data_Types; 
generic 

type  Velocity  Is  digits  <>; 
type  Altitude  Is  range  <>; 
package  Abstract_Nav1gat1on_Type  Is 

type  Nav1gat1on_Mode1  Is  private; 
procedure  Compute_Earth_Relat1ve_Hor1zontal_ 

Velocities 

(Updating:  In  out  Navi gat lonjtodel ) ; 

Conversion  routines 
function  Current_Alt1tude 

(Based_0n:  Nav1gat1on_Mode1 ) 
return  Altitude; 

private 

type  Nav1gat1on_Model  Is 
record 

M1ss11e_Veloc1ty:  Velocity; 

M1ss11e_Alt1tude:  Altitude; 

end  record 

end  Abstract_Nav1gat1on_Type; 

Figure  24.  Package  Specification  Using  the  Atstract  Oata  Type 

This  method  offers  essentially  the  same  advantages  as  the  state 
machine  method  In  regards  to  data  typing  and  operations.  Because  the  part 
designer  chooses  the  data  structures,  the  designer  will  also  create  all 
operations  needed  to  support  these  structures.  The  chief  disadvantage  Is, 
again,  the  need  to  perform  data  conversion  each  time  a  Navigation  Model 
object  Is  updated.  Unlike  the  state  machine,  the  Abstract  Oata  Type  user 
must  use  the  data  structure  which  the  part  designer  created.  If  for 
efficiency  reasons,  the  user  does  not  like  this  structure  he  must  rewrite  the 
package  specification  and  the  package  body. 
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f.  Skeletal  Code  Method 


The  Skeletal  approach  gives  the  user  of  a  part  great  flexibility. 
The  raw  Input  to  this  method  Is  not  complete  Ada  code,  as  In  the  other 
methods,  but  Is  a  template  which  may  be  manipulated  manually  by  a 
template-driven  editor,  or  automatically  by  an  expert  system.  A  sample  of  a 
template  Is  shown  In  Figure  25. 

function  Compute_Earth_Relat1ve_Hor1zontal_Veloc1t1es 
(Nomlnal_East_Veloc1ty , 

Nom1nal_North_Veloc1ty, 

Wander_Angle_  :  In  _ ; 

East_Veloc1ty, 

North_Veloc1ty  :  out  _ ); 

Figure  25.  Specification  of  a  Function  Using  the  Skeletal  Method 

When  used  In  a  manual  mode,  the  user  edits  the  skeletal  code  Into 
his  existing  design  and  Inserts  data  types,  operators,  and  other  Identifiers 
as  required.  When  used  In  conjunction  with  an  expert  system,  the  expert 
system  will  prompt  the  user  for  Information  It  needs  to  fill  In  the  blanks. 
Information  which  will  again  Include  specific  data  types  and  operations. 
While  the  manual  approach  would  require  the  user  to  complete  much  of  the 
environment  for  the  skeletal  part,  rules  programmed  Into  the  expert  system 
allow  the  system  to  complete  the  Ada  code,  filling  In  types,  operators,  and 
any  additional  subprograms  not  In  the  skeletal  version. 

While  the  manual  approach  seems  flexible  and  simple  to  use,  the 
difficulty  of  this  method  Is  the  need  to  create  an  environment  for  each  Ada 
part  built  from  the  skeletal  code.  If  two  or  more  designers  are  working  on 
similar  parts,  they  may  choose  different  values  for  completing  the  template, 
requiring  duplication  of  environmental  data.  There  would  also  be  a  tendency 
to  avoid  strong  data  typing  because  of  the  overhead  Involved  In  creating  the 
functions  and  operators  for  strongly  typed  data.  The  expert  system  concept 
offers  the  long  term  solution  to  these  difficulties,  by  building  the 
environment  as  a  by-product  of  the  user  dialogue.  As  the  user  specifies 
types,  for  example,  the  expert  system  can  define  the  functions  and  operators 
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for  those  types.  The  expert  system  can  also  Inform  the  user  of  existing 
parts  which  may  serve  his  design. 

3.  SELECTED  DESIGN  APPROACH 

The  CAMP  program  has  developed  a  design  approach  based  on  the  generic  and 
overloaded  methods  which  permit  reuse  of  compiled  parts  from  a  CAMP  Program 
Library  as  well  as  the  reuse  of  source  code  from  a  CAMP  Text  Library.  These 
two  modes  of  usage  are  referred  to  as  the  bundled  and  unbundled  forms  and 
are  Illustrated  In  Figure  26. 


Figure  26.  Modes  of  Using  CAMP  Parts 
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In  the  bundled  form,  parts  are  provided  to  the  user  In  packages.  The 
packages  are  wlthed  by  the  user  and  the  user  calls  the  parts  through  the 
package  mechanism.  For  packages  which  contain  generic  subprograms,  a  package 
Is  wlthed  and  generic  parts  are  Instantiated  for  future  use.  In  the 
unbundled  form,  the  user  can  access  parts  as  code  segments,  which  are 
Included  In  his  own  text  files.  These  code  segments  may  consist  of  context 
clauses,  packages,  generic  parts,  subprogram  specifications,  or  subprogram 
bodies . 

The  library  technique  specified  by  the  Ada  standard  ( MI L-STO-1 81 5A)  will 
support  the  CAMP  Program  Library.  The  CAMP  top-level  design  specifies  parts 
In  the  bundled  form  which  have  been  compiled  and  are  accessed  via  the  Ada 
context  clause.  The  development  and  use  of  the  CAMP  Text  Library  will 
require  an  Include  facility,  via  a  pragma,  to  permit  the  reuse  of  source 
code.  This  facility  was  part  of  earlier  Ada  standards  and  Is  a  feature 

supported  by  many  of  the  commercially  developed  Ada  Programming  Support 

Environments. 

a.  Support  Provided  from  the  Program  Library 

The  CAMP  Ada  Library  will  provide  flexibility  through  the  use  of 
generic  parts  as  well  as  ease  of  use  through  packages  of  typical 
Instantiations  of  these  parts.  Generic  units  offer  the  user  a  high  degree  of 
flexibility  by  allowing  the  part  user  to  use  predefined  data  types  or  to 
create  his  own.  Should  he  choose  to  do  the  Instantiation  using  predefined 
types,  the  design  will  provide  him  with  packages  of  operators  and  predefined 
functions  using  these  data  types.  The  Instantiation  can  then  use  these 
operators  and  functions  as  defaults,  easing  the  user's  responsibilities.  If 
the  user  defines  his  own  types  for  use  by  the  generic  functions,  he  must  also 

create  his  own  operators  and  functions  and  use  these  In  the  Instantiation  of 

the  generic  subprograms.  He  should  be  cautioned  that  use  of  float  for  all 
types  will  negate  type  checking. 


51 


The  CAMP  program  library  will  also  provide  packages  of  typical 
Instantiations  of  the  generic  parts.  The  criteria  used  for  selecting  these 
Instantiations  will  be  sensible  combinations  of  data  types.  This  application 
of  the  overloaded  method  provides  protection  against  misuse  of  a  part, 
supported  by  the  compiler,  through  strong  data  type  checking  of  parameters. 

A  package  of  navigation  parts  using  metric  linear  measurements  and  radians 
for  angular  measurements  would  be  an  example  of  such  a  combination.  Figure 
27  Illustrates  the  methods  of  using  parts  which  the  Program  Library  will 
support. 

The  CAMP  program  assumes  that  the  expert  system  will  not  be  a  part 
of  the  Initial  Ada  parts  system,  and  therefore  the  program  library  must 
provide  the  user  with  all  the  parts  he  might  potentially  need.  The  support 
required  of  the  CAMP  program  library  Increases  the  work  of  the  original 
designer  of  a  part,  and  also  Increases  the  overall  number  of  parts,  but  It  Is 
the  only  method  that  can  address  all  of  the  user  requirements,  without  an 
expert  system. 


USER 

PROGRAM 
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b.  Support  Provided  from  the  Text  Library 


The  CAMP  text  library  will  support  the  construction  of  source  code 
from  text  segments.  These  fragments  will  Include  subprogram  specifications 
and  bodies,  generic  parts,  context  clauses,  data  structure  declarations,  and 
other  Ada  program  fragments.  The  Ada  Instruction  "pragma  Include  (Text 
File)"  will  permit  the  user  to  Insert  these  textual  segments  Into  program 
source  code.  (This  pragma  was  part  of  the  original  Ada  standard  but  was  then 
dropped.)  The  support  provided  by  the  pragma  Include  (If  present)  will 
permit  the  part  user  to  reuse  code  at  the  lowest  part  level,  obviating  the 
need  for  establishing  a  context  of  complete  packages  where  he  only  needs  a 
small  number  of  entitles  from  each  package.  Figure  28  Illustrates  the 
methods  of  accessing  text  from  the  Text  Library. 


CONTEXT 

CLAUSES 


SUBPROGRAM 

SPECIFICATIONS 

Figure  28.  Support  Provided  by  the  Text  Library 


53 


c.  Method  of  Accessing  Parts 


The  CAMP  design,  both  the  bundled  and  unbundled  modes,  provides  a 
variety  of  different  ways  to  access  parts;  Figure  29  Illustrates  these 
methods.  At  the  center  of  the  figure  Is  the  specification  of  the  Part 
Package  (Item  a)  containing  specifications  of  generic  subprograms.  These 
subprogram  specifications  are  themselves  text  which  has  been  Included  from 
other  source  files,  labeled  Generic  Subprogram  Specifications  (Item  b).  The 
bodies  of  the  subprograms  are  Individual  source  files  labeled  Generic 
Subprogram  Bodies  (Item  c).  The  generic  subprogram  specifications  and  bodies 
are  Included  as  text  In  the  Part  Package  Body  (Item  d).  The  packages  labeled 
Sample  Instantiations  (Item  e)  are  packages  which  contain  Instantiations  of 
generic  subprograms  from  the  Part  Package  Specification.  The  user  (Item  f) 
has  the  following  choices: 


O 


© 


WITH  AND  PERFORM  INSTANTIATION 


Figure  29.  Methods  of  Accessing  Parts 
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(1)  "With"  one  or  more  Sample  Instantiation  packages  which  will 
provide  subprograms. 

(2)  "With"  the  Part  Package  and  perform  Instantiations  for  the 
subprograms  which  are  needed. 

(3)  "Include"  files  from  the  Generic  Subprogram  Specifications  and 
create  Instantiations  from  these  generics. 

(4)  "With"  one  or  more  Generic  Subprograms  and  perform 
Instantiations  on  these  Individual  generics. 

(5)  "Include"  files  from  the  Generic  Subprogram  Bodies  Into  a  user 
package  or  program. 

d.  Efficiency  of  Parts 

The  efficiency  of  Individual  parts  Is  a  major  requirement  of  the 
CAMP  design.  The  goal  of  this  requirement  Is  to  assure  that  reusable  parts 
will  be  as  efficient  as  parts  which  have  been  custom-designed.  The  Issue  of 
efficiency  Is  most  apparent  In  the  design  of  mathematical  functions  which  are 
widely  used  by  the  primary  missile  functions. 

The  development  of  reusable  parts  for  vector  operations  Illustrates 
the  design  of  reusable  parts  which  realize  the  goal  of  efficiency;  Figure  30 
shows  a  portion  of  this  design.  Operations  on  a  vector  may  be  performed  In  a 
generalized  mode,  without  restrictions  on  the  size  of  the  vectors  or 
matrices.  This  method  Is  referred  to  In  Figure  30  as  the  casual  user. 
However,  many  of  the  missile  operations  which  need  these  parts  are  dealing 
with  three  dimensional  coordinate  axes.  The  CAMP  design  Includes  a  special 
package  of  coordinate  vector  and  matrix  operations  to  handle  this 
requirement.  The  actual  Implementations  of  these  operations  are  made 
efficient  by  unfolding  the  computations,  recognizing  that  loop  operations  are 
needed  for  generality,  but  are  not  needed  for  coordinate  data  structures, 
where  there  are  always  three  elements.  Use  of  this  technique,  referred  to  as 
the  user  concerned  with  efficiency,  will  utilize  three  computations  to 
perform  a  vector  operation  rather  than  nine  as  required  by  the  general 

looping  technique.  This  approach  shows  the  gains  which  can  be  made  In  terms 

of  the  flexibility  and  utility  of  the  parts  but  at  some  Increased  cost  In 

design. 
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GENERIC  PACKAGE 


CASUAL 

USER 


USER 

CONCERNED 

WITH 

EFFICIENCY 


USER  WITH 

SEVERE 

TIMING 

CONSTRAINTS 


A:SCALAR; 

B,C:VECTOR, 


C:  -  B/A;  - 


A:  SCALAR; 
B,C:COORDINATE_ 
VECTOR; 


C:  *  B/A;- 


ArSCALAR; 
B,C:COORDINATE_ 
VECTOR  _  WITH  _Z 


B/A;- 


THREE 


Q  COORDINATES  IS  K  >1. 

»  ELEMENTS  IS  DIGITS  <  >. 


O  SCALAR  IS  ELEMENTS; 

O  VECTOR  IS  ARRAY 
!  (POSITIVE  RANGE  <  »  OF 
|  ELEMENTS; 

COORDINATE  .VECTOR  IS  ARRAY 
|  (COORDINATES)  OF  ELEMENTS; 

<$>  COORDINATE  _  VECTOR  _  WITH  _  Z  _  0 
IS  ARRAY  (COORDINATES! 

OF  ELEMENTS. 

"/"  (VECTOR,  SCALAR! 

•T  (COORDINATE_ VECTOR.  SCALAR) 
*7"  (COORDINATE  _ VECTOR  _ 
WITH_Z_0,  SCALAR) 
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Figure  30.  Addressing  Efficiency  Through  Reusable  Parts 

Many  of  the  primary  missile  functions  operate  on  coordinate  data 
where  one  or  two  dimensions  do  not  apply.  For  example,  angular  velocity  will 
exist  In  only  two  dimensions  and  gravity  In  only  one.  The  CAMP  design  makes 
effective  reuse  of  parts  by  providing  sparse  vector  operations,  which  make 
use  of  the  fact  that  there  will  be  zeroes  In  the  vector.  The  navigation 
functions  which  must  operate  on  vectors  of  these  types  can  reuse  parts  from 
the  coordinate  vector  packages.  Sparse  matrix  operations  are  used  by  the 
user  with  severe  timing  constraints  In  Figure  30. 

A  significant  factor  In  the  design  of  these  parts  Is  that  they  are 
accomplished  using  overloading.  The  data  type  chosen  by  the  user  to 
represent  his  vector  will  determine  the  exact  operation;  It  need  not  be 
explicitly  stated  by  the  user  program.  For  example,  If  the  user  defines  his 
vector  as  a  Coord1nate_Vector  the  vector  part  performing  three  operations 
will  be  automatically  Invoked. 
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The  CAMP  design  for  trigonometric  operations  also  Illustrates  the 
addressing  of  efficiency  Issues.  The  design  Includes  a  standard 
trigonometric  package  exporting  trigonometric  operations  which  are  required 
by  the  missile  functions.  The  design  also  Includes  a  polynomial  package 
which  exports  functions  which  may  provide  greater  precision,  speed,  or  memory 
economy,  If  those  are  requirements.  Computational  short  cuts  to  maximize  the 
reuse  of  Intermediate  values  are  another  part  of  the  design.  An  example  of 
this  method  Is  the  SINE-COSINE  function  which  returns  both  the  sine  and 
cosine  of  an  angle  where  the  algorithm  uses  the  same  Intermediate  terms  In 
computing  each  value. 

4.  DOCUMENTATION  APPROACH 

The  documentation  of  the  Top-Level  design  for  the  CAMP  parts  must 
describe  the  architecture  of  part  packages  and  detail  the  Interfaces  between 
packages.  This  will  require  TLCSC's  which  address  the  Issues  shown  In  Figure 
31.  These  requirements  must  be  met  both  In  the  TLDD  and  In  the  header  of  the 
design  code  Itself.  Figure  32  Illustrates  the  structure  for  this  Information 
both  In  the  design  code  header  and  In  the  TLOO. 

The  DOD-STD-2167  Data  Item  Descriptor  for  the  Software  Top-Level  Design 
Document  (DI-MCCR-80012)  does  not  adequately  cover  these  Issues.  The  OID 
seems  to  be  directed  towards  a  design  which  features  data  passing  through 
shared  data,  rather  than  parameter  passing,  and  parameterless  subroutines 
employed  for  structural  reasons,  rather  than  functional  or  object-oriented 
decomposition.  This  architecture  for  a  TLCSC  Is  not  compatible  with  the 
object-oriented 


•  The  package  context  (the  list  of  external  packages  which  are 
needed) 

•  The  decomposition  of  the  TLCSC  Into  LLCSC's 

•  Ada  Design  of  the  specification  of  the  TLCSC  and  Its  LLCSC's 

•  Major  entitles  which  are  local  to  the  package  body 

•  Externally  callable  entries  (where  tasking  Is  used) 

•  Requirements  for  Instantiation  and  other  use  of  a  part 

•  Global  processing  and  output 

Figure  31.  Issues  Which  Must  Be  Addressed  In  the  TLDD 
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TLCSC  Name 
ID  Number 
Purpose 

Requirements  Trace 
Context 

-  Exported  Entities 

-  local  Entities 

-  Additional  coding  information 


package  XVZ  is 
function  .  .  . 
function  .  . 


and  XYX; 

TLDO  SECTION 

DESIGN  CODE  HEADER 

(  3.6.4  X.2.2.V  LLCSC  Y 

3. 6.4. *.2.2.1  LLCSC  1 

3.6.4. x  TLCSC  NAME 

3.6.4. x.  1  INPUTS 

3.6.4  x.1.1  GENERIC 

3.6.4.  x.2  TLCSC  DECOMPOSITION 

3.6.4. x. 2. 1  REQUIREMENTS  ALLOCATION 

3.6  4  x  2.2  LLCSC  DESIGN 

Figure  32.  Structure  for  Design  Header  and  TLOD 
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nature  of  an  Ada  package  specification.  Therefore,  the  TLDO  Is  not 
sufficient  for  our  documentation  needs. 

Much  of  the  Information  that  properly  belongs  to  a  TLCSC  which  has  been 
designed  using  Ada  has  been  placed  In  the  Software  Detail  Design  Document 
(e.g.,  the  TLCSC  decomposition,  and  LLCSC  Interfacing).  The  CAMP  project  has 
determined  that  this  Information  must  appear  In  the  top-level  design 
description.  This  will  require  that  the  DID  for  top-level  design  be  modified 
to  Include  architectural  Information  highlighting  the  structure  of  the  TLCSC 
down  to  the  unit  level,  where  units  are  externally  callable.  It  should  also 
Include  structural  Information  which  Is  required  for  the  detailed  design  of 
these  external  Interfaces.  In  Ada  terms,  the  TLDD  will  document  the  Ada 
specification  plus  major  data  structures  and  processing  needs  of  the  package 
body.  Figure  33  Illustrates  the  top-level  design  of  a  typical  TLCSC. 

The  documentation  of  the  top-level  design,  will  In  general  refer  back  to 
the  Software  Requirements  Specification  for  the  top-level  algorithmic 
description.  This  should  be  sufficient  Information  for  the  needs  of  detailed 
design,  to  avoid  redundancy  between  the  SRS  and  the  TLDD.  For  algorithms 
which  have  not  been  adequately  documented  In  the  SRS,  especially  those  In  the 
domain  Independent  area,  the  TLDD  must  Include  Input-processing-output 
Information. 

The  Detailed  Design  Document  will  describe  the  Implementation  of  all  of 
the  top-level  design  requirements,  for  both  the  bundled  version  of  parts  and 
the  unbundled  version.  The  ODD  must  contain  the  full  package  body  for  all 
TLCSC's  plus  those  source  code  segments  which  are  used  to  build  the  Ada 
design  code.  The  actual  code  for  the  DDO  will  consist  of  a  series  of  pragma 
Include  (text  file)  statements.  The  text  that  has  been  Included  using  this 
method  will  be  expanded  for  documentation  purposes.  The  DDO  will  Include  the 
design  code  for  Individual  parts,  the  CAMP  library  structure  and  the  CAMP 
source  text  structure. 
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with  Baaic_Data_Typea; 

package  NorthPointing_Navigation_Parta  la 

package  BDT  ranaaaa  Baoic_Data_Typee; 
package  Trig  ranaaaa  BDT. Trig; 


ganarlo 

typa  Valoclty.Vactor  la  private; 
typa  Rotatioi\_Rate_Vector  ia  privata; 
typa  Acceleratlon_Vector  ia  privata; 
with  function  (Left,  Right  i  Rotation_Jlate  Vector) 
ratum  Rotatlon_JUte_Vector  la  or 
with  function  Croaa.Product  (La ft  i  Rotatlon_Rate_Vector; 

Right  t  Velocity  Vector) 
ratum  Acoelaratlon_Vactor  la  <>; 
function  Ganar ic_Coaputa_Cor iol  iojkocelaratlon 

(Valocity.ln  <  in  Velocity.Vector; 
Rho.ln  t  In  RotationJUtaJ/actori 

oaaga.ln  t  In  Rotation^Aate_Vector) 
ratum  Accalaration_Vactorr 


ganar ic 

typa  EarthPoaition  ia  dlglta  <>; 
typa  Diatanca  la  dlglta  o; 

typa  Dlatanca.Vactor  la  array  (BDT.  NorthPoint  lngJUcaa) 
of  Diatanca; 

with  function  "/"  (Left,  Right  t  Diatanca) 

ratum  Trlg.Trig_Valua  la  <>; 

with  function  ■/"  (Laft  i  Diatanca;  Right  i  Trig.Trlg_Valua) 
ratum  Diatanca  la  09 
with  function  Sin  (Anglo  t  Barth  poa  it  Ion) 

ratum  Trig.TrIg_Valua  la  <>; 
with  function  Coa  (Angla  t  Earth_Poaition) 

ratum  Trlg.Trig_Valua  ia  <>; 
function  Ganar io_Coaputa_JUdll_of  .Curvature 
(Latitude  t  in  EarthPoaition; 

Altitude  1  In  Dlataiw  »)  ratum  Dlatanoe_Vector; 

and  NorthPoint ln«LNavl«atlotuParta; 


Figure  33.  Top-Level  ADL  Design  of  a  Typical  TLCSC 
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1.  PURPOSE 

The  objective  of  this  analysis  was  to  determine  the  effect  that  differing 
degrees  of  software  reusability  would  have  on  software  development 
productivity. 


2.  DEFINITIONS 

While  various  metrics  have  been  proposed  to  measure  software  development 
productivity,  experience  has  shown  that  the  traditional  Lines  Of  Code  per 
Han  Month  (LOC/MM)  metric  is  highly  correlated  to  roost  proposed  alternatives, 
and  that  the  average  software  engineering  manager  finds  It  simpler  to  grasp 
than  the  proposed  alternatives.  While  one  might  decry  the  use  of  such  a 
metric  for  aesthetic  reasons,  no  viable  alternative  has  yet  passed  the  test 
of  time.  For  these  reasons,  productivity  (P)  was  defined.  In  terras  of  the 
total  size  (S)  of  the  software  system  (as  measured  In  LOC)  and  the  effort  (E) 
required  to  develop  the  code  (as  measured  In  man-months),  as  follows. 

P  =  S  /  E  (1) 

Since  this  analysis  is  concerned  with  measuring  the  change  In 
productivity  (the  dependent  variable)  as  opposed  to  absolute  productivity 
measurements,  the  following  definition  will  be  used  for  the  degree  of 
productivity  Improve  ment  ( P%)  when  comparing  the  productivity  of  a  project 
which  did  not  use  parts  (P^p)  and  the  productivity  of  a  project,  developing 
the  same  software,  using  parts  (Pp). 
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(?) 


"  =  (PP  -  %P>  7  PNP 

This  equation  can  be  simplified  as  follows. 

PX  ■  (pp  /  PNp)  -  1  (3) 

For  example.  If  project  A  and  B  are  developing  the  same  software  system, 
and  project  A  achieves  100  LOC/HH  using  parts  while  project  B  achieves  80 
LOC/MM  not  using  parts  then  the  degree  of  productivity  Improvement  Is  25 
percent. 

PX  -  (100  /  80)  -1  *  0.25 

The  Independent  variable  In  this  analysis  Is  the  degree  of  software  reuse 
(RX).  This  will  be  defined  In  terms  of  the  amount  of  code  developed  (SQ) 
and  the  total  size  of  the  software  system  (S  )  as  follows. 

RX  *  (ST  -  SQ)  /  ST  (4) 

Which  can  be  simplified  as  follows. 

<  t  * 

RX  =  1  -  (SD  /  ST)  (5) 

For  example,  If  project  A  developed  10,000  lines  of  code  and  reuses  a 
number  of  software  parts  which  provided  another  3,000  lines  of  code,  then  Its 
degree  of  software  reuse  Is  23  percent. 

RX  =  1  -  (10,000  /  13,000)  -  0.23 
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3.  APPROACH 


Determining  the  effect  of  reusing  software  parts  on  software  development 
productivity  Involves  a  comparison  between  a  classical  (l.e.,  no  software 
reuse)  project  and  a  project  developing  the  same  software  using  parts.  While 
the  use  of  empirical  data,  collected  during  a  controlled  experiment,  would 
lend  credence  to  any  results  obtained,  such  experiments  have  proven 
Impractical.  Few  organizations  have  the  resources  to  fund  parallel  efforts 
on  real  applications,  and  experiments  based  on  contrived  applications  often 
do  not  generalize  to  real  applications. 

For  this  reason,  an  analytical  approach  for  evaluating  the  effect  of 
software  reuse  was  used.  In  other  words,  a  predictive  mathematical  model  (M) 
of  software  cost  would  be  used  to  determine  the  effort  required  to  develop 
software  as  a  function  of  the  software's  size  and  other  cost  drivers.  The 
software  size  and  other  cost  drivers  would  be  varied  to  account  for  the 
differences  In  using  and  not  using  parts. 

While  the  exact  results  obtained  using  this  approach  could  be  questioned 
(e.g.,  Was  an  appropriate  software  cost  model  used?  Were  appropriate 
parameter  values  selected?),  there  Is  sufficient  empirical  evidence  that  the 
model  and  the  parameter  values  chosen  are  close  enough  to  the  real  world  to 
make  the  general  nature  of  the  results  valid. 


4.  PREDICTIVE  MODEL 

The  Construction  Cost  Model  (C0C0M0)  developed  by  Barry  Boehm  was  used  as 
the  analytic  model  In  this  analysis.  This  model  was  chosen  based  on  Its  wide 
acceptance  by  the  aerospace  software  engineering  community  and  the  fact  that 
It  Is  one  of  the  few  models  which  have  been  rigorously  defined  and  documented 
(see  Reference  34).  Although  C0C0M0  exists  In  several  versions  (each  version 
requiring  more  Information  from  the  estimator  and  In  turn  providing  more 
accurate  estimates)  the  Basic  C0C0M0  version  was  sufficient  for  this 
analysis.  The  following  equations  define  the  basic  C0C0M0  model. 
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(6) 

(7) 

(8) 

Where 

a  =  2.4  and  b  =  1.05  If  mode  =  organic 

a  3  3.0  and  b  =  1.12  If  mode  =  semidetached 

a  x  3.6  and  b  =  1.20  If  mode  x  embedded 

Figure  34  defines  the  C0C0M0  modes  and  Figure  35  defines  the  variables  In 

these  equations. 


AAF  x  (0.4J0MF  ♦  (0.3)CMF  ♦  (0.3)IMF 
S  =  CN  ♦  Ca(AAF  /  100) 


Organic 


Semidetached 

Embedded 


This  type  of  software  Is  typically  developed  by  small  teams, 
has  relatively  relaxed  design  constraints,  negotiable 
requirements,  and  usually  does  not  Involve  the  concurrent 
development  of  hardware/procedures. 

This  type  of  software  Is  a  midpoint  between  embedded  and 
organic. 

This  type  of  software  typically  has  severe  requirements  and 
design  constraints,  Is  tightly  coupled  to  complex  hardware, 
software  and  procedure  Interfaces,  and  often  requires 
Innovative  algorithms. 


Figure  34.  C0C0M0  Modes 
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[AAF]:  The  Adaptation  Adjustment  Factor  Is  a  percentage  which  weights  the 

existing  code  which  Is  to  be  adapted  by  the  amount  of  modification 
needed  to  use  It  In  the  new  software 

[DMF]:  The  Design  Modification  Factor  Is  the  percentage  of  the  design  of 

the  adapted  software  which  has  to  be  modified  to  suit  the  new 
project 

[CMF]:  The  Code  Modification  Factor  Is  the  percentage  of  the  code  of  the 

adapted  software  which  has  to  be  modified  to  suit  the  new  project 

[IMF]:  The  Integration  Modification  Factor  Is  the  percentage  of 

additional  effort  required  to  Integrate  the  adapted  software  Into 
the  new  software  as  compared  to  the  effort  normally  required  to 
Integrate  software  of  a  comparable  size 

[S]  This  Is  the  total  size  of  the  software  system  as  measured  In  KLOC 

(thousands  of  lines  of  code) 

[CN)  This  Is  the  amount  of  new  code  developed  for  the  project  as 

measured  In  KLOC  (thousands  of  lines  of  code) 

[CAJ  This  Is  the  amount  of  existing  code  adapted  for  use  In  the  project 

as  measured  In  KLOC  (thousands  of  lines  of  code) 

[E]  This  Is  the  software  development  efforts  (design  through  testing) 

as  measured  In  KLOC  (thousands  of  lines  of  code) 

Figure  35.  C0F0M0  Equation  Variables 


An  example  (not  based  on  parts  reuse)  will  serve  to  Illustrate  the  use  of 
this  model.  The  TOMEX  (Totally  Made-Up  Example)  project  has  determined  that 
It  will  develop  10,000  lines  of  code  and  that  It  can  adapt  another  3,000 
lines  of  code  from  the  already  completed  ANMEX  (Another  Made-Up  Example) 
project.  The  TOMEX  project  Involves  the  developed  of  real-time  embedded 
software  with  tight  constraints  on  Interfaces.  The  TOMEX  software  Is  being 
developed  at  the  same  time  as  the  hardware  devices  with  which  It  must 
Interface. 

From  an  analysis  of  the  3,000  lines  of  code  of  the  ANMEX  project  which  Is 
targeted  for  reuse.  It  has  been  determined  that,  on  average: 
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•  20  percent  of  the  design  of  the  adapted  code  will  have  to  be 
modified, 

•  50  percent  of  the  code  will  have  to  be  modified  (those  portions 
which  were  written  In  assembly  language  will  need  recoding  since 
TOMEX  Is  using  a  different  target  processor  than  ANNEX),  and 

•  the  Integration  of  the  adapted  code  Into  the  TOMEX  software  system 
will  require  30  percent  more  effort  than  If  we  had  developed  new 
code  for  the  equivalent  functions  (l.e.  It  will  be  slightly  more 
difficult  to  Integrate  the  existing  parts  than  to  Integrate  new  code 
becai se  of  the  need  to  work  with  someone  else's  Interfaces). 

This  description  leads  to  the  following  values  for  the  COCOMO  Input 
parameters . 

CN  =10  KLOC 
CA  =  3  KLOC 

OMF  =  20  X 
CMF  =  50  X 
IMF  =  30  X 
MODE  =  Embedded 

Me  can  now  perform  the  following  calculations. 

AAF  =  (0  4)20  +  (0.3)50  +  (0.3)30  =  32X 
S  =  10  +  3(32/100)  =  10.96  KLOC 

E  =  3.6  (10. =•  63.7  manmonths 
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5.  ANALYSIS 


Using  the  COCOMO  equation  for  effort,  the  equation  for  productivity  (Eq 
1)  can  be  reformulated  as  follows. 

P  =  S  /  aSb  (9) 

This  equation  can  be  simplified  as  follows. 

P  =  1  /  aSb'1  (10) 

If  one  assumes  (for  the  moment)  that  there  Is  no  dc  lopment  effort 
expended  when  parts  are  reused,  then  the  productivity  of  the  parts  approach 
(Pp)  can  be  stated  In  terms  of  the  size  of  the  total  software  (S^.)  and 
the  effort  required  to  develop  the  new  code  as  follows. 

Pp  -  ST  /  a  (S0)b  (11) 

Equation  5  can  be  reformulated  to  provide  a  definition  of  the  size  of  the 
newly  developed  code  In  terms  of  the  degree  of  software  reuse  as  follows. 

S0  =  (l-RX)Sy  (12) 

Using  equation  12  with  equation  11  the  following  equation  Is  obtained. 

Pp  •  ST  /  a  [(l-RX)ST)b  (13) 

Then  using  a  transformation  similar  to  that  used  to  develop  equation  10,  we 
can  simplify  this  as  follows. 

Pp  -  1  /  a(l-RX)b(ST)b_1  (14) 
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The  productivity  Improvement  equation  ( EQ  3)  can  now  be  written  as  follows. 


1  /  a(l-RX)b(ST)b~1 
PX  = _ -  1 

1  /  a(ST)b_1 

Which  can  be  simplified  as  follows. 

PX  =  (l-RX)  b  -  1 

Figure  36  graphically  depicts  equation  16. 


(15) 


(16) 


LOG  (X  Pioductivity  Improvement) 


Degree  of  Reuse 

Figure  36.  The  Effect  of  Software  Reuse  on  Productivity 
Assuming  no  Usage  Cost 


It  can  be  seen  that  Figure  36  presents  an  unrealistic  view  of  using 
parts.  As  the  degree  of  reuse  approaches  100  percent,  the  degree  of 
productivity  Improvement  approaches  Infinity.  The  missing  factor  Is  that 
there  Is  a  developmental  cost  to  reuse  parts.  The  C0C0M0  Adaptation 
Adjustment  Factor  (AAF),  see  Equation  6,  offers  a  good  method  of  Including 
this  parts  usage  cost.  It  Is  assumed  that  when  parts  are  being  reused  (as 
opposed  to  non  parts  reusability)  that  the  parts  will  be  used  without  any 
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significant  redesigning  or  recoding.  For  the  purpose  of  this  analysis.  It 
was  estimated  that  5  percent  of  the  design,  and  10  percent  of  the  code  of  the 
parts  would  have  to  be  modified  be  In  a  typical  application.  While  It  Is 
preferable  that  parts  should  be  designed  to  be  reused  as  they  exist  (l.e.,  0 
percent  design  and  code  modification),  this  Is  an  Ideal  goal  which  will 
seldom  be  achievable  In  real  applications. 

It  Is  also  estimated  {based  on  CAMP  experience)  that  the  cost  to 
Integrate  the  parts  Into  the  new  software  will  require  10  percent  additional 
effort  as  compared  to  the  effort  to  Integrate  new,  customized  code  which 
would  perform  the  same  functions  as  the  parts  used.  This  cost  Includes  such 
factors  as  Identifying  the  appropriate  parts,  analyzing  the  parts  for 
suitability,  and  writing  the  newly  developed  software  In  such  a  manner  that 
It  complies  with  the  Interfaces  of  the  parts.  These  assumptions  yield  the 
following  AAF. 

AAF  =  (0.4)5  ♦  (0.3)10  +  (0.3)10  =  8% 

The  AAF  value  will  be  used  to  define  the  parts  usage  cost  factor  (U)  as 
follows. 

U  =  AAF  /  100 

The  productivity  of  the  parts  approach  (Pp)  can  now  be  stated  as  follows 
using  equation  7  and  9. 

Pp  =  ST  /  a  [  (1-RX)St  ♦  (RX)St(U)  ]b  (17) 

The  productivity  Improvement  using  parts  can  be  stated  as  follows. 

ST  /  a  [  (1-RX)St  +  (RX)ST(U)  ]b 

PX  = _ -  1  (18) 

ST  /  a  [Sy]b 
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This  equation  can  be  simplified  as  follows. 

PX  *  [l-RX(l-U)]'b-l  (19) 

Figures  37,  38,  and  39  depict  the  behavior  of  this  equation  for  differing 
values  of  U.  R%  and  P.  For  example,  from  Figure  37  It  can  be  seen  that  when 
the  degree  of  reuse  Is  50  percent  and  the  cost  factor  Is  10  percent,  the 
productivity  gained  Is  100  percent  (log^lOO]  *  2). 


Degit*  of  Rmm 

Figure  37.  The  Effect  of  Software  Reuse  on  Productivity 
(Embedded  Software) 
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I 


LOG  |f  Pioductmty  ImpiwmMt) 


DtftM  of  Route 

Figure  38.  The  Effect  of  Software  Reuse  on  Productivity 
(Semidetached  Software) 


LOG  (%  Pioductmty  Improvement) 


Degiee  of  Reuoe 

Figure  39.  The  Effect  of  Software  Reuse  on  Productivity 
(Organic  Software) 
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Figure  40  depicts  a  slightly  different  view  of  the  same  equation.  In 
this  figure,  the  factors  controllable  by  an  organization  are  on  the  axis,  and 
the  result  (l.e.  the  productivity  Improvement  Is  represented  by  contour 
lines). 


PRODUCTIVITY  IMPROVEMENT  ON  CONTOUR  LINES 


Figure  40.  The  Effect  of  Software  Reuse  and  the  Cost  of  Using  the  Parts 
on  Productivity  for  Embedded  Software 


When  the  degree  of  reusability  Is  100  percent  (l.e.,  R=1),  equation  19 
transforms  to  the  following. 

PX  =  U_b  -1  (20) 

Figure  41  depicts  the  behavior  of  this  equation  for  differing  values  of  U. 

For  example,  if  the  usage  cost  Is  30  percent,  then  the  maximum  productivity 
Improvement  for  an  organic  software  project  (at  100  percent  reuse)  will  be 
254  percent  (log1Q[254]  =  2.4). 
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Pails  Usage  Coat  Factoi 


Figure  41.  The  Effect  of  the  Cost  of  Using  Parts  on  Productivity 


Figure  42  depicts  the  curve  of  equation  20  for  a  usage  cost  of  8  percent 
(see  previous  rationale).  At  recent  STARS  meetings,  there  have  been 
statements  that  30  percent  Is  a  good  estimate  for  the  degree  of  software 
reuse  that  can  be  expected  In  the  near  term.  Using  these  two  factors  we 
arrive  at  the  conclusion  that  the  near  term  productivity  Improvement  should 
be  47  percent. 
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LOG  (%  Productivity  Improvement) 


Defies  of  Reuse 

Figure  4?.  The  Effect  of  Software  Reuse  on  Productivity 
Assuming  an  8%  Parts  Usage  Cost  Factor 
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SECTION  VI 

EVALUATION  OF  THE  JAPANESE  SOFTWARE  REUSE  EFFORTS 


1.  Introduction  .  75 

2.  General  Observations  .  76 

3.  Toshiba  Corporation  .  79 

4.  Yokosuka  Electrical  Communication  Lab  .  84 

5.  Nippon  Electric  Company  .  87 

6.  Fujitsu  . 91 

7.  Hitachi  Software  Engineering  Co.,  LTD  .  94 

8.  Company  X  . 97 

1 .  INTRODUCTION 

During  the  week  of  21  January  1985,  three  members  of  the  CAMP  team 
visited  the  six  Japanese  companies  listed  In  Figure  43  for  the  purpose  of 
evaluating  the  software  reusability  programs,  tools,  and  techniques  used  by 
those  companies.  Although  this  trip  was  specifically  designed  to  examine  the 
area  of  software  reusability,  our  discussions  with  the  Japanese  ranged  far 
beyond  this  one  area.  This  trip  was  conducted  In  response  to  a  contractual 
requirement  of  the  CAMP  program. 


Toshiba  Corporation 

Yokosuka  Electrical  Communication  Laboratory,  NTT 
Nippon  Electric  Company  (NEC)  Corporation 
Fujitsu,  Ltd. 

Hitachi  Software  Engineering 
Company  X  (requested  anonymity) 

Figure  43.  Companies  Visited 


75 


The  general  observations  made  by  the  authors  are  discussed  In  paragraph 
2.  Detailed  descriptions  of  our  visit  to  each  company  are  contained  In  the 
paragraphs  3  through  8. 

It  should  be  noted  that  In  most  cases  the  authors  met  with  senior 
managers  and  software  engineers  from  application  areas  other  than  missile 
software  systems.  In  many  cases,  the  Individuals  we  talked  with  were  not 
working  directly  on  real  time,  embedded  applications  although  they  appeared 
to  be  knowledgeable  of  their  companies'  efforts  In  this  type  of  application. 


2.  GENERAL  OBSERVATIONS 


a.  Software  Reusability 


Software  reusability  efforts  found  within  the  Japanese  companies 
visited  appeared  to  be  equivalent  to  that  found  within  most  American 
companies,  which  Is  to  say  that  reuse  of  software  Is  In  the  early  stages  of 
Implementation.  In  the  past,  most  of  the  Japanese  reusability  efforts  have 
been  centered  around  two  approaches-  the  tailoring  of  entire  systems  and  the 
use  of  application  generators;  In  contrast,  the  CAMP  project  Is  concerned 
mainly  with  a  parts  approach  to  reusability 

The  process  of  tailoring  an  existing  system  to  meet  a  new  set  of 
requirements  was  one  that  we  observed  In  most  of  the  companies  we  visited. 
This  approach,  which  we  refer  to  as  system  reusability,  Is  based  on  the 
premise  that  within  an  application  area  most  systems  tend  to  have  a  common 
structure  and  that  11.  Is  cost  effective  to  start  the  development  of  a  new 
system  from  a  baselined  version  of  a  similar  system  which  can  then  be 
modified  to  achieve  tne  new  set  of  objectives 

For  a  number  of  years  the  Japanese  have  been  claiming 
extraordinarily  high  software  development  productivity  figures.  It  turns  out 
that  these  numbers  are  mainly  a  result  of  using  application  generators  within 
very  narrow  and  well  defined  application  areas  such  as  banking  and 
man-machine  Interface  construction.  An  applications  generator  Is  a 
software  system  that  can  produce  new  software  systems  when  provided  with  the 
requirements  of  the  new  application  by  the  user. 
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Although  all  the  companies  we  visited  were  examining  the  feasibility 
of  a  parts  approach  to  software  reusability,  only  one  of  them  seemed  to  have 
progressed  beyond  the  Initial  study  phases.  Yet,  even  this  one  company  had 
not  Implemented  a  full-scale  program. 

b.  Tools  &  Techniques 

During  the  past  several  years  there  have  been  several  articles  In 
the  American  software  literature  which  have  given  the  Impression  that 
Japanese  companies  have  made  significant  and  widespread  use  of 
state-of-the-art  software  engineering  tools  and  techniques.  In  many  cases 
the  authors  of  these  articles  have  not  explicitly  made  this  observation,  but, 
the  American  software  community  has  drawn  this  conclusion.  Although  we  saw 
and  heard  about  a  number  of  tools  and  techniques  during  our  visit,  there  are 
several  factors  which  lead  us  to  conclude  that  the  popular  Impression  Is 
false. 

Like  most  American  companies,  the  Japanese  companies  have  software 
technology  groups  or  laboratories  which  develop  new  tools  and  techniques.  We 
were  told  by  the  companies  we  visited  that  many  of  the  tools  we  saw  and  heard 
about  were  still  In  the  laboratory  and  not  In  widespread  use  throughout  their 
organizations. 

In  the  opinion  of  the  authors,  many  of  the  tools  we  saw  were  not 
very  technologically  Innovative.  They  performed  relatively  straight-forward 
tasks  using  classical  techniques.  The  major  reason  for  this  seems  to  be 
because  the  Japanese  utilize  a  large  number  of  non-degreed  personnel,  thus 
their  tools  are  designed  for  the  novice  software  engineer.  It  Is  our  opinion 
that  many  of  the  tools  we  saw  would  be  frustrating  to  American  software 
engineers.  These  tools  typically  provide  only  one  path  to  any  objective, 
which  Is  by  means  of  a  rigidly  controlled,  step-by-step  procedure.  There  Is 
no  way  to  abbreviate  this  procedure  even  If  the  user  Is  proficient  with  the 
process  and  knows  what  steps  are  not  needed  and  therefore  can  be  skipped. 

Many  of  the  tools  we  saw  would  have  limited  utility  In  American 
companies  because  their  major  goal  was  to  help  Japanese  programmers  overcome 
the  problems  that  arise  from  using  conventional  programming  languages  such  as 
Ada,  Fortran,  COBOL,  and  ' C * .  These  languages  consist  of  English  language 
commands,  and  what  Is  often  overlooked  by  members  of  the  American  software 
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community  Is  that  the  commands  within  these  programming  languages  are  used  as 
Is  by  the  Japanese,  (l.e.,  there  Is  not  a  Japanese  version  of  COBOL  or 
Fortran  or  Ada).  Although  Japanese  high  school  students  are  taught  English, 
the  average  programmer  has  difficulty  thinking  In  this  language.  For  this 
reason,  many  of  the  Japanese  tools  are  designed  to  give  their  programmers 
facilities  to  write  Japanese  statements  and  have  those  statements  converted 
automatically  to  the  English  language  commands  of  the  programming  language 
being  used. 

c.  Staffing 

One  surprising  observation  made  by  the  authors  was  the  extensive  use 
made  of  non-degreed  personnel  In  the  companies  we  visited.  Although  the 
numbers  varied  among  companies,  between  40  percent  and  60  percent  of  the 
personnel  Involved  In  applications  software  development  within  these 
companies  had  only  a  high  school  education. 

These  employees  receive  between  6  and  12  months  of  training  within 
the  company  and  are  used  Initially  as  software  technicians  (l.e.  performing 
coding  and  unit  testing  functions).  Much  of  the  training  they  receive  Is 
on-the-job  training  as  opposed  to  forma!  course  work.  Once  proficient,  they 
have  the  same  opportunities  to  advance  within  the  company  as  degreed 
personnel . 

One  factor  that  makes  this  type  of  staffing  feasible  Is  the  low  turn 
over  found  within  most  Japanese  companies.  This  allows  the  Investment  In 
training  to  be  amortized  over  the  many  years  of  employment. 

d.  Facilities 

The  authors  were  somewhat  surprised  to  observe  the  software 
development  facilities  used  by  most  of  the  companies  visited.  In  many  cases 
the  old  bull  pen  was  still  In  widespread  use.  We  were  also  surprised  by  the 
use  of  centralized  terminal  areas  as  opposed  to  terminals  at  the  programmers' 
work  site.  We  were  Informed  by  several  companies  that  plans  called  for 
upgrading  these  facilities  In  the  near  future. 
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e.  Ada 


Almost  all  of  the  companies  visited  were  extremely  Interested  In  Ada 
and  were  evaluating  It  for  future  use.  Some  of  the  companies  had  performed 
significant  work  In  this  area.  Including  the  development  of  Ada  compilers  and 
tools  to  be  used  with  Ada  (e.g.,  symbolic  debuggers). 

Most  of  the  companies  visited  perform  work  for  the  Japanese  Defense 
Agency  (JDA)  and  were  closely  tracking  JDA's  study  of  Ada.  Since  our  visit, 
we  have  learned  that  JDA  did  mandate  the  use  of  Ada. 

f.  Expert  Systems 

The  authors  were  somewhat  surprised  by  the  low  level  of  work  being 
performed  by  most  of  the  companies  visited  In  the  application  of  expert 
system  technology  to  software  engineering  problems.  Although  most  of  the 
companies  had  some  efforts  underway  In  this  area,  they  seemed  to  be  mostly 
research  projects. 

3.  TOSHIBA  CORPORATION 

Toshiba  Corporation  was  visited  on  Monday,  21  January  1985.  This  meeting 
took  place  at  the  new  Toshiba  Headquarters  building  located  In  Tokyo.  Figure 
44  lists  the  representatives  from  Toshiba  who  were  present  at  this  meeting. 
Figure  45  shows  the  agenda  for  the  meeting. 
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Koshl  Asakawa.  Senior  Manager 

Defense  Market  Planning,  Defense  Products  Division 
Akira  Ito,  General  Manager 

Systems  &  Software  Engineering  Division 
Ikumune  Takahashl,  Senior  Manager 

Software  Engineering  Department,  Systems  G  Software  Engineering  Division 
Dr.  Hldeo  Nakamura,  Assistant  Specialist 
Systems  &  Software  Engineering  Division 
Yutaka  Ohfude,  Manager 

Systems  &  Software  Engineering  Division 
H.  Morloka,  Senior  Manager 

Advanced  Programs  Engineering,  Komukal -Works 
M.  Ikeda,  Oeputy  Manager 

Advanced  Systems  Engineering,  Avionics  Engineering,  Komukal-Horks 

S.  Klnoshlta,  Senior  Specialist 

Sasic  Software  Design  4  Development,  Ohme  Works 

T.  Tanaka,  Specialist 

Heavy  Apparatus  Engineering  Laboratory,  Heavy  Apparatus  Group 
S.  Yamamoto,  Manager 

Eng.  Administration  &  Factory,  Information  Systems,  Fuchu-Works 
Ms.  M.  O'oe,  Engineer 

Power  Generation  Control  Systems.  Fuchu-Works 

Figure  44.  Toshiba  Contacts 
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Figure  45.  Toshiba  Meeting  Agenda 


a.  Products 


Toshiba  develops  software  for  many  different  types  of  commercial  and 
military  products,  some  of  which  are  listed  In  Figure  46. 


Office  Automation  —  computers,  data  processing  systems,  word  processors, 

optical  page  readers,  plain-paper  copiers,  facsimile 
machines,  etc. 


Labor  Saving  .  letter  &  package  sorting  M/C,  automatic  fare 

Equipment  collection  systems,  banking  equipment,  etc. 


Medical  Equipment  —  computed  tomography  scanners,  ultrasound  and  X-ray 

diagnostic  equipment,  nuclear  medicine  equipment,  etc. 
Telecommunication  —  broadcasting  and  telecommunications,  UHF 


Equipment  radio  relay  systems,  telephone  switchboards 

Air  Port  Equipment  ...  air  traffic  control  systems,  runway  lighting  systems, 

etc. 

Space  Programs  .  broadcasting  satellite,  engineering  test  satellite, 

etc. 

Defense  Programs  .  missiles,  etc. 


Figure  46.  Toshiba  Product  Lines 

b.  Languages 

Toshiba's  past  missile  software  applications  have  been  written 
primarily  In  assembly  language.  This  has  been  due  to  the  severe  time  and 
storage  constraints.  However,  they  are  studying  the  use  of  Ada  and  other 
Higher  Order  Languages  because  the  Japan  Defense  Agency  (JDA)  Is  doing  so. 
Like  most  of  the  Japanese  firms  doing  business  with  the  JDA,  Toshiba  will  be 
greatly  affected  by  any  decision  the  JDA  makes  with  respect  to  the  use  of  a 
given  HOL. 
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c.  Reusability 


Toshiba's  main  approach  to  reusability  Is  the  reuse  of  systems, 
rather  than  Individual  software  components  within  the  system.  An  entire 
software  package  Is  standardized,  so  that  In  the  development  of  future 
similar  applications,  this  system  serves  as  a  baseline  from  which  changes  can 
be  made.  Their  reported  productivity  using  this  approach  Is  2,800  lines  of 
code  per  man-month  based  on  the  use  of  assembly  language. 

They  are  Just  now  starting  to  work  on  software  parts  reusability  as 
opposed  to  system  reusability.  There  has  been  no  major  reuse  of  missile 
software  yet.  Reusability  at  the  Fuchu  Works  (non-missile  applications)  Is 
much  further  along.  Reusability  Is  promoted  by  rewarding  software  reuse.  If 
a  software  engineer  develops  and  registers  a  reusable  components  some  type  of 
monetary  reward  Is  given  to  him.  When  a  reusable  software  component  Is 
Identified,  It  Is  registered  at  a  software  engineering  center  and  entered 
Into  the  software  database.  Software  can  be  registered  at  either  the  local 
level  or  at  the  head  office. 

A  parts  catalog  Is  not  yet  part  of  the  Software  Work  Bench  (SWB)  at 
the  Fuchu  Works.  Application  specific  reusable  parts  are  collected  Into  a 
textual  catalog  of  sorts.  Toshiba  believes  that  consideration  of  reuse  of 
software  must  begin  at  the  design  level.  They  also  have  Identified  the  reuse 
of  software  components  as  a  major  goal  In  the  future. 

d.  Tools 

Fuchu  Works  has  the  SWB  (Software  Work  Bench)  which  consists  of 
components  to  support  software  design.  Implementation,  testing,  and 
maintenance,  project  management,  and  software  quality  control.  PROSUS 
(Process  Oriented  System  Support  Software)  provides  data  management  system, 
I/O  service  system,  system  support,  system  monitoring  system.  IMAP 
(Integrated  Management  and  Production  System)  Is  Intended  to  provide  a 
software  CAO  approach 


Toshiba  Is  working  on  graphical  techniques  (standardized  display 
patterns)  and  estimates  that  these  techniques  should  be  available  for 
software  development  In  approximately  2  years. 

e.  Staffing 

Within  Toshiba,  45  percent  of  employees  are  engineers  and  technical 
workers  (3500);  of  those,  25  percent  perform  software  related  functions. 

Sixty  percent  of  their  software  workers  are  non-degreed,  but  undergo  a 
one -year  Internal  software  training  course. 

There  Is  some  overlap  In  the  types  of  jobs  performed  by  degreed  and 
non  degreed  personnel.  The  basic  functions  that  must  be  performed  are  as 
follow:  requirements  specification,  system  design,  program  design,  coding, 
and  testing.  Generally,  1  to  5  years  Is  spent  coding;  even  degreed  personnel 
start  In  this  area.  After  coding,  personnel  move  on  to  requirements  and 
system  design.  Non  degreed  personnel  do  have  an  opportunity  for  advancement. 

f.  enforcement  of  Methodologies 

Enforcement  of  methodologies  Is  generally  by  consensus  which  may 
take  many  years  to  reach;  this  can  vary  somewhat  by  project. 

g.  Knowledge  Engineering 

Toshiba  Is  currently  working  on  a  knowledge  engineering  approach  to 
software  retrieval. 

h.  Miscellaneous 

Quality  Assurance  R&D  at  loshlba  has  produced  a  system  referred  to 
as  ESQUT  (Evaluation  of  Software  Quality  from  the  User's  Viewpoint).  They 
have  started  to  use  this  system  In  office  automation  applications. 
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4.  YOKOSUKA  ELECTRICAL  COMMUNICATION  LABORATORY,  NTT 


Yokosuka  Labs  was  visited  on  Tuesday,  72  January  1985.  This  meeting  took 
place  at  their  Kanagawa  facility.  Figure  47  lists  the  representatives  from 
Yokosuka  Labs  who  were  present  at  this  meeting.  There  was  no  explicit  agenda 
for  the  meeting,  but  after  a  brief  Introduction,  the  authors  were  given  a 
number  of  demonstrations  of  software  tools.  These  were  followed  by  an  MDAC 
presentation  on  CAMP  and  an  Informal  discussion  on  a  wide  range  of 
software  related  topics. 


Sadahlro  Isoda 

Senior  Staff  Engineer 
Ruolchl  Hosoya 

Chief  of  Processing  Programs  Section,  Oata  Processing  Olvlslon 
Dr.  Klrnlo  Ibukl 

Olrector,  Ibukl 's  Research  Section 
Dr.  Aklhlro  Mashlmoto 

Oeputy  Director,  Data  Processing  Development  Division 
Figure  47.  Yokosuka  Labs  Contacts 


a.  Products 

l he  Electrical  Communications  Lab  Is  similar  to  Bell  Labs  In  that  It 
Is  the  reseat ch  lab  for  Nippon  Telegraph  and  Telephone  Public  Corporation 
(NTT) .  Some  of  the  areas  of  research  and  development  that  are  pursued  at  the 

lab  are  summarized  in  Figure  18. 

b.  Languages 

Yokosuka  makes  use  of  CHILL,  assembly  languages,  and  Is  currently 
getting  involved  with  Ada.  Their  Interest  In  Ada  stems  from  an  Interest  In 
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Transmission  .  digital  networks,  optical  fiber  transmission, 

radio  transmission,  mobile  communication, 
satellite  communication 

Information  Processing  .  data  communication  network,  Information 

processing  hardware  and  software,  production  of 
software.  Intelligent  processing 

Customer  Equipment  .  telephone  sets,  data  terminals,  speech 

processing,  character  recognition 

Visual  Communication  .  facsimile  communication,  facsimile  equipment, 

picture  processing 


Integrated  Communications  ...  business  communication  systems,  document 

communications  communication  processing  systems 

Figure  48.  Yokosuka  ECL  R&D  Areas 


portability  of  software  among  machines. 

They  are  developing  Ada  Interfaces  to  a  library  of  existing  routines 
that  are  written  In  assembly  language;  there  are  currently  approximately  140 
of  these  software  parts.  Yokosuka  has  an  Ada  (subset)  compiler  and 
associated  tools  under  development  (DIPS  -  Dendenkosha  Information  Processing 
System  -  Ada).  They  are  also  working  on  a  syntax-directed  editor.  A  3-year 
Ada  development  project  calls  for  the  Involvement  of  approximately  50 
people.  Yokosuka  also  has  plans  to  develop  cross-compilers  for  micros  (8086, 
Z80,  68000).  Their  long-range  plans  call  for  the  development  of  an  Ada 
machine. 

c.  Software  Reusability 

Yokosuka  Laboratories  has  only  recently  begun  to  study  software 
reusability;  the  Ada  Interfaces  to  assembler  routines  are  a  step  In  that 
direction.  A  form  has  been  developed  to  capture  the  necessary  Information 
for  a  parts  catalog.  Retrieval  of  parts  will  be  by  keyword. 
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d.  Tools 

The  engineers  at  Yokosuka  expressed  an  Interest  In  developing  a 
software  parts  composition  system,  but  work  has  not  yet  begun  In  this  area. 
They,  like  the  CAMP  team,  have  rejected  a  universal  software  generation 
system  approach  An  attempt  Is  being  made  to  develop  common  software 
development  tools  for  CHILL  and  Ada. 

HCP  (Hierarchical  and  Compact  Description  Chart)  provides  standards 
for  graphical  description  of  data  structures  and  program  structure,  and  for 
the  layout  on  paper  of  the  data  flow  and  program  description.  HD  (HCP  Chart 
Designing  system)  Is  a  prototype  software  CAO  system. 

WAVE  (Widely  Available  Versatile  Environment)  Is  Intended  to  be  an 
Integrated  software  development  environment  that  facilitates  the  collection 
and  transfer  of  software  development  knowledge. 

SL  (Superb  Data  Oriented  Language)  consists  of  5  sublanguages  that 
allow  for  the  automatic  generation  of  COBOL  application  programs  from  program 
specif Icatlons  written  In  SL. 

ADAM  (Ada  Parts  Management  Tool)  Is  Intended  to  perform  three 
primary  functions:  (1)  register  and  retrieve  software  parts  and  display 
parts  specification,  (2)  consistency  checking,  (3)  notification  of  need  to 
recompile  due  to  program  modifications. 

VIPS  is  a  visual  debugger  that  displays  dynamic  flow  of  control  and 
changes  to  data 

e.  Staffing 

!he  employees  within  the  lab  Itself  were  highly  educated:  10  percent 
have  PhDs,  70  percent  have  Masters  degrees,  and  20  percent  have  Bachelors 
degrees  The  app! Icatlons  programmers  at  Yokosuka  are  largely  high  school 
graduates  who  are  hired  upon  graduation  and  put  through  an  Internal  training 
program.  The  management  at  Yokosuka  made  the  observation  that  It  was  easier 
to  train  young  people  In  Ada  and  CHIN  than  It  was  to  re- train  their  older 
programmers . 
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f.  Enforcement  of  Methodologies 


The  discussion  of  enforcement  of  methodologies  centered  around  the 
topic  of  reusable  software.  See  paragraph  c  for  coverage  of  this  topic. 

g.  Knowledge  Engineering 

Yokosuka  Labs  Is  not  yet  using  a  knowledge  engineering  approach  to 
software  retrieval. 


5.  NIPPON  ELECTRIC  COMPANY 

NEC  was  visited  on  Wednesday  and  Thursday,  23  &  24  January  1985.  The 
Wednesday  meeting  took  place  at  the  Fuchu  plant;  the  Thursday  meeting  was 
held  at  the  Tokyo  office.  Figure  49  lists  the  representatives  of  NEC  who 
were  present  at  the  meetings. 

The  meeting  at  Fuchu  consisted  of  presentations  by  NEC  personnel,  and  an 
overview  of  the  CAMP  program  by  MDAC.  This  was  followed  by  a  general 
discussion  and  a  tour  of  the  NEC  facilities.  Thursday's  meeting  In  Tokyo 
began  with  an  overview  of  software  engineering  technology  at  NEC,  and  a  brief 
presentation  on  CAMP  by  MOAC.  This  was  followed  by  a  tour  and  demonstrations 
of  a  number  of  software  tools.  The  meeting  ended  with  a  general  discussion. 

a.  Products 

NEC  concentrates  on  developing  hardware  and  software  for  the 
communications  area.  It  provides  products  for  both  the  private  and 
government  sectors,  and  has  customers  both  In  Japan  and  abroad.  The  product 
areas  are  summarized  In  Figure  50. 
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Dr.  M.  Yamaguchl,  Assistant  General  Manager 
Radio  Application  Division 
T.  Kato,  Supervisor 

Microcomputer  Software  Dept.,  Software  Product  Engineering  Laboratory 
Y.  Ishlda,  Senior  Program  Mgr 

Special  Integrated  System  Division 
T.  Saya,  Manager 

?nd  Common  Software  Development  Dept.,  Basic  Software  Development  Oept. 

T.  Ogou,  Engineering  Manager 

2nd  Common-Software  Development  Dept.,  Basic  Software  Development  Dept. 

N.  Uklta,  Senior  Program  Mgr 

Dept,  of  System  Management,  NEC  Aerospace  Systems  Ltd. 

H.  Shlrakura,  Manager 

Special  Systems  Dept.,  NEC  Aerospace  Systems  Ltd. 

K.  Mlwa,  Senior  Program  Manager 

International  Government  Sales  Group 
H.  Nagasawa,  Senior  Program  Mgr 

Maritime  Defense  Systems,  2nd  .IDA  Sales  Division 

O.  Shlyo,  Supervisor 

Software  Engineering  Department,  Software  Engineering  Product  Laboratory 

S.  Mlsakl,  Manager 

Interface  Architecture  Department,  Software  Product  Engineering  Laboratory 

Figure  49.  NEC  Contacts 


Swl tchlng  1 ransml ss lon/Termlnal s 

Radio  Computers/Industrial  Electronic  Systems 

Electron  Devices  Home  Electronics 

Research  &  Development 


Figure  50.  NEC  Product  Line 
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b.  Languages 


The  'C'  programming  language  Is  used  quite  extensively,  as  Is  COBOL 
for  business  applications.  NEC,  like  many  of  the  companies  we  visited,  Is 
awaiting  a  decision  by  the  JOA  on  the  use  of  Ada.  They  are  developing  an 
Ada  compiler  on  their  DIPS  computer  targeted  to  the  DIPS;  the  compiler  Is 
written  In  CPL  (Common  Programming  Language),  a  PL/1  subset. 

NEC  has  Identified  several  Issues  surrounding  the  Introduction  of 
Ada  In  Japan,  such  as  should  there  be  domestic  development  of  Ada  compilers 
and  tools  or  should  they  be  Imported  from  the  U.S.,  and  how  can  support  for 
Ada  be  developed? 

c.  Software  Reusability 

The  management  at  NEC  thinks  that  reuse  of  software  Is  one  solution 
to  the  problem  of  limited  resources  and  Increasing  demand  for  software.  NEC 
has  not  yet  Implemented  the  concept  of  reusability;  they  are  currently 
solving  the  problem  with  Increased  man-power.  Several  research  projects  are 
underway  to  prove  the  concept  of  reusable  software  parts.  One  project 
entails  having  an  engineer  Identify  reusable  parts  In  order  to  build  and 
organize  a  parts  library. 

d.  Tools 

The  observation  was  made  by  a  representative  from  NEC  that  formal 
specification  languages  are  good  for  analysis  but  not  good  for  people  (l.e., 
they  make  It  difficult  to  communicate  between  many  different  types  of 
people).  NEC  would  like  to  develop  graphical  software  development 
environment. 

SEA/1  (Software  Engineering  Architecture)  Is  a  COBOL-based  parts 
definition  language.  Work  Is  currently  proceeding  on  prototype  programs 
(l.e.,  templates  or  skeletons  for  software  parts)  mainly  In  the  business  and 
aerospace  areas.  They  have  not  yet  Incorporated  an  expert  system  approach. 
Retrieval  of  parts  Is  by  keyword. 
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SDMS  (Software  Development  and  Maintenance  System)  Is  a  design 
system  using  a  graphical  technique;  It  utilizes  underlying  knowledge  bases. 

STEPS  Is  a  tool  for  producing  standardized  documentation.  SPD 
(Structured  Programming  Diagram)  Is  a  technique  used  to  design  well 
structured  programs;  It  has  been  proposed  for  an  ISO  standard. 

e.  Staffing 

NEC  hires  many  new  graduates  (approximately  1000  a  year;  most  are 
engineers).  Because  of  the  shortage  of  engineers,  NEC  Informed  the  authors 
that  they  also  employ  large  numbers  of  women  a'  technicians  and  coders,  and 
cross  train  large  numbers  of  non-engineering  graduates.  NEC  management 
Informed  the  authors  that,  to  a  great  extent,  they  view  women  as  a  temporary 
labor  source.  They  reported  that  most  women  remain  In  the  work  force  for 
only  about  5  years  after  graduation  from  high  school.  Both  groups  are 
provided  with  ln-house  training  that  consists  of  3  months  of  collective 
training,  and  then  on-the-job  training. 

f.  Enforcement  of  Methodologies 

Discussions  of  enforcement  centered  around  enforcement  of  software 
reuse.  NEC  management  seemed  to  feel  that  users  can't  be  forced  to  reuse 
parts . 

g.  Knowledge  Engineering 

NEC  Is  working  on  automatic  program  generation  In  the  banking 
domain  They  are  making  use  of  a  frame  driven  system  that  Incorporates  both 
forward  and  backward  chaining. 

h.  Miscellaneous 

Sixteen  percent  of  NEC's  sales  are  to  NTT  and  the  government,  50 
percent  are  to  ihe  private  sector;  34  percent  are  overseas.  Purchases  from 
NEC  amount  to  12.5  percent  of  total  JDA  expenditures. 
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NEC  has  developed  the  NEDIP  (Nippon  Electric  Dataflow  Image 
Processing  System)  computer,  a  non-Von  Neumann  machine  that  operates  at  about 
the  speed  of  a  Cray. 


6.  FUJITSU 

Fujitsu  was  visited  on  Thursday,  24  January  1985.  Figure  51  lists  the 
representatives  of  Fujitsu  who  were  present  at  the  meeting.  Figure  52 
presents  the  meeting  agenda. 


Masakatsu  Suglmoto,  Deputy  Manager 

Artificial  Intelligence  Lab,  Fujitsu  Laboratories  Ltd. 

Kunlakl  Mori,  Section  Manager 

Software  Development  Planning  Group,  Development  Planning  Office 
Dr.  Toru  Nakagawa,  Manager 
1 1 AS- SIS,  Fujitsu  Limited 
Mr.  Haraguchl 

Development  Department,  Software  Division,  Computer  Systems 
Tomoharu  Mohrl,  Researcher 

Artificial  Intelligence  Lab,  Fujitsu  Laboratories  .Ltd . 

Mr.  Suglmoto,  Deputy  Manager 

Artificial  Intelligence  Lab,  Fujitsu  Laboratories  Ltd. 

Makoto  TsuJIgadoh,  General  Manager 

Research  Management  Division,  1 1 AS- SIS ,  Fujitsu  Limited 
Sanya  Uenara 

Tools  and  Methodologies  Section,  Software  Lab,  Fujitsu  Laboratories  Ltd. 

Figure  51.  Fujitsu  Contacts 
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Introduction 

Software  Development  Environments  In  Fujitsu 

Software  Components  Technology  In  Fujitsu 

Introduction  to  PARADIGM 

Approaches  of  Fujitsu  Laboratory 

Research  Direction 

MDAC  Presentation  on  CAMP 

Technical  Exchange  on  Ada 

General  Discussion 

Figure  5?.  Fujitsu  Meeting  Agenda 


a.  Products 

Fujitsu  Is  Involved  In  telecommunications,  data  processing, 
semiconductors,  and  components.  Figure  53  summarizes  the  major  product  lines. 


Man  machine  Interface  .  . 


Telecommunications  ... 

Information  Processing 

Electronic  Devices  ... 


CAD  System,  Intelligent  robots,  optical  sensing  and 
recognition,  speech  processing,  Kanjl  recognition, 
printer  and  facsimile  equipment,  displays,  medical 
equipment 

communications  networks,  optical  communications 
systems,  radio  communications  systems 
Intelligent  Information  processing  system,  file 
memory 

high  electron  mobility  transistor,  silicon  LSls, 
Josephson  junctions,  device  coding  techniques,  fine 
pattern  technology,  semiconductor  material  and 
processing  techniques,  optical  semiconductor 
devices.  Infrared  devices,  optical  circuit  components 


Figure  53.  Fujitsu  Product  Lines 
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b.  Languages 


COBOL  Is  used  extensively  In  their  business  applications.  They  are 
currently  Investigating  the  feasibility  of  Ada  by  using  NYU/Ada  Ed  on  a  VAX 
11/780.  They  are  Interested  In  obtaining  other  (better)  Ada  compilers;  they 
do  not  currently  have  plans  to  develop  a  compiler  In  house. 

c.  Software  Reusability 

Fujitsu  personnel  made  the  observation  that  reuse  of  software  by 
Itself  Is  not  enough;  three  approaches  (new  languages,  development 
methodology,  and  reusable  software)  must  be  combined  Into  a  software  parts 
approach.  Software  must  be  designed  for  reuse.  The  first  step  Is  to  find 
commonality  so  that  parts  can  be  developed.  Engineers  at  Fujitsu  have 
Identified  three  types  of  software  parts:  black  box  parts,  patterns  (which 
provide  user  with  skeletal  algorithms  and  the  user  Is  shown  where 
modifications  are  needed),  and  good  examples.  This  taxonomy  of  parts  closely 
matches  the  CAMP  simple,  generic,  and  schematic  parts. 

Fujitsu  Is  trying  to  develop  a  componentlzed  software  approach 
(l.e.,  develop  a  database  of  software  parts  with  unified  Interfaces).  They, 
like  others,  think  that  reusable  components  must  be  registered. 

d.  Tools 

PARADIGM  Is  a  collection  of  standard  programs  and  data.  The 
programs  consist  of  program  patterns  and  parts  (l.e.,  actual  code  segments); 
the  data  consists  of  data  screen  and  report  format  source  code.  There  are 
two  types  of  paradigms:  standard  (l.e.,  those  supplied  by  Fujitsu)  and 
non  standard  (l.e.,  those  created  by  users).  PARADIGM  Is  for  medium-sized 
business  applications.  The  developers  expect  that  Its  use  can  cut  software 
development  time  In  half  by  the  second  or  third  use  of  PARADIGM  (l.e.,  as 
users  move  up  their  learning  curve). 

PDAS  (Programming  and  Design  Assist  System)  Is  designed  to 
computerize  and  standardize  documents  with  the  eventual  goal  of  automatically 
generating  code  from  those  documents. 
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SDL  (Functional  Specification  Description  Language)  provides  an 
environment  for  developing  electronic  switching  system  software.  SDL  makes 
use  of  knowledge  engineering.  Both  PDAS  and  SDL  are  In  the  prototyping  stage 

SDT  (Software  Design  Technique)  Is  a  structured  design  technique 
that  can  be  used  as  an  alternative  to  HIPO. 

e.  Staffing 

Staffing  was  not  discussed  at  this  meeting. 

f.  Enforcement  of  Methodologies 

Ihe  discussion  In  this  area  centered  on  software  reusability. 

g.  Knowledge  Engineering 

Fujitsu  has  an  Artificial  Intelligence  Lab,  but  the  technology  does 
not  seem  to  be  applied  at  a  significant  level  In  the  applications  area. 


7.  HITACHI  SOFTWARE  ENGINEERING  CO.,  LTD. 

Hitachi  Software  Engineering  was  visited  on  Friday,  25  January  1985. 

This  meeting  took  place  at  the  Hitachi  facility  located  In  Yokohama.  Figure 
54  lists  the  representatives  from  Hitachi  who  were  present  at  this  meeting. 
Figure  55  shows  the  agenda  for  the  meeting. 
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Tomoo  Hatsubara,  Chief  Engineer 

Masahlro  Hlral,  Manager,  Test  and  Assurance  Department 
Masafuml  Shlmoda,  Manager,  Overseas  Project 
Shohel  Tomlt,  Overseas  Project 

Figure  54.  Hitachi  Software  Engineering  Co.,  Ltd.  Contacts 


09:00 

09:15 

10:15 

10:45 

11:45 


09:15  Greeting  and  Introduction 

10:15  MDAC  Presentation  on  CAMP 

10:45  Hitachi  Presentation  on  Productivity  (SKIPS) 

11:15  Hitachi  presentation  on  Quality  Control 

12:30  Discussion 


Figure  55.  Hitachi  Meeting  Agenda 


a.  Products 

Hitachi  Software  Engineering  Co.  Is  concerned  primarily  with  the 
development  of  software  products  for  Hitachi  computers.  The  Hitachi  software 
product  line  Is  summarized  In  Figure  56. 

b.  Languages 

The  use  of  assembly  languages  Is  decreasing,  while  the  use  of  COBOL, 
PL/1,  and  HPL  (a  PL/l-type  language)  Is  Increasing.  The  variety  of  languages 
makes  It  difficult  to  Impose  standards  and  reuse.  Work  Is  proceeding  on 
implementation  of  an  Ada  compiler  for  the  Hitachi  M  series  (this  Is  similar 
to  IBM  3081). 
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On-line  Application  Systems:  Banking,  Stock  Information  Systems,  Taxation 
Systems,  Patent  Information  System,  Computer-Aided  Traffic  Control  System 
Minicomputer  Applications:  Automated  Warehouse  System,  Hotel  Reservation  and 
Account  System,  Cash  Dispenser  Control  System,  Telex  Fxchange  System 
Graphics  and  Numerical  Control 
Operating  Systems 

Programming  Languages  and  Compilers:  Fortran,  PL/1,  COBOL,  RPG, 
special-purpose  languages 

Database  Management  Systems:  For  Hitachi  M  series  of  computers 
Electronic  Switching  Systems 

Microprocessor  applied  Hardware  Systems:  Chinese  character  data  entry 
system,  banking  teller  machine 

Figure  56.  Hitachi  Software  Engineering  Co.  Product  Lines 


c.  Software  Reusability 

Hitachi  has  not  yet  been  successful  at  reuse  of  software  In  embedded 
systems,  but  the  use  of  standard  program  formats  In  banking  applications  has 
been  fairly  successful.  They  think  this  Is  due  to  the  high  degree  of 
commonality  found  In  banking  applications.  When  starting  a  project,  they  not 
only  decide  on  a  methodology  and  tools,  they  also  decide  on  what  parts  (l.e., 
standard  formats)  will  be  reused. 

d.  Tools 

Tools  are  developed  In  part  to  overcome  the  language  problem. 

STAMPS  (Standardized  Modular  Programming  System)  makes  use  of  a  combination 
of  a  business  oriented  language  and  semi-parametric  programming  to  generate 
COBOL  source  code.  This  product  Is  actually  being  exported.  Hitachi  makes 
use  of  a  variety  of  tools  to  aid  In  the  testing  of  software. 
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e.  Staffing 


Sixty  percent  of  Hitachi's  software  engineers  are  university 
graduates.  The  company  Invests  much  money  In  lifetime  training  of  employees; 
this  Is  feasible  because  of  the  low  turn-over  In  personnel. 


f.  Enforcement  of  Methodologies 

The  discussion  centered  on  enforcement  of  software  reusability. 

g.  Knowledge  Engineering 

There  was  not  sufficient  time  to  explore  this  matter  In  detail  with 
Hitachi  personnel. 

h.  Miscellaneous 

There  Is  a  great  deal  of  concern  with  QA  at  Hitachi  Software 
Engineering.  A  number  of  programs  have  been  Implemented  to  Increase  the 
quality  of  the  software  products  produced. 


8.  COMPANY  X 

Company  X  was  visited  on  Friday,  25  January  1985.  There  was  no  formal 
agenda  for  this  meeting.  At  the  end  of  the  meeting,  this  company’s  chief 
spokesman  requested  that  his  company's  name  not  be  mentioned  In  any  external 
reports . 

a.  Products 

Company  X  Is  a  defense  contractor,  working  on  various  missile 
developments . 
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b.  Languages 


Company  X  makes  use  of  assembly  language  for  missile  applications. 
They  also  use  *C'  and  Pascal  for  non-missile  applications.  Company  X,  like 
most  of  the  other  companies  visited,  has  not  yet  made  a  decision  on  the 
appl Icabl 1 1 ty  of  Ada  to  their  problem  domain.  They  are  awaiting  guidance 
from  JOA. 

c.  Software  Reusability 

This  company  Is  moving  towards  reuse  of  software  modules  (1.e.t  they 
think  software  reuse  Is  necessary),  but  has  not  yet  Implemented  a  coherent 
approach  to  reusability.  Language  and  hardware  differences  have  been  major 
obstacles  to  software  reuse. 

d.  Tools 

No  one  set  of  tools  or  methodologies  Is  used  across  all  projects  at 
Company  X,  but  little  by  little,  standard  practices  are  being  Implemented. 

e.  Staffing 

All  software  engineers  at  Company  X  are  college  graduates;  most  have 
degrees  In  electrical  or  electronics  engineering.  College  graduates 
experience  1  2  years  of  on  the  Job  training  In  software  design  and 
development  Company  X  feels  that  It  takes  5-6  years  of  experience  for 
engineers  to  be  able  to  properly  perform  the  design  task.  The  first  3  years 
of  employment  are  similar  to  an  apprenticeship.  Company  X  encourages  their 
engineers  to  keep  current  with  technology  via  self  study. 

f.  Enforcement  of  Methodologies 

Enforcement  of  methodologies  Is  via  audits  and  walkthroughs. 

g.  Knowledge  Engineering 

Company  X  Is  not  performing  any  known  work  In  this  area. 
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SECTION  VII 

EVALUATION  OF  THE  STARS  SOFTWARE  MEASUREMENT  FORMS 

1 .  General  Comments  .  99 

2.  Comments  on  Specific  Forms  ...  101 


1.  GENERAL  COMMENTS 

Part  of  the  CAMP  project  Involved  the  completion  of  applicable  STARS 
Baseline  Software  Measurement  Oata  Item  Descriptions.  The  following  six 
forms  were  completed: 

•  Resource  Expenditure  Detailed  Report 

•  Software  Development  Environment  Summary  Report 

•  Software  Characteristics  Detailed  Report 

•  Software  Change/Error  Document 

•  Software  Evaluation  Report  (REQ) 

•  Software  Evaluation  Report  (PRELIM) 

MDAC-STL  supports  the  STARS  effort  to  obtain  software  cost  data  (we  have 
had  a  similar  effort  underway  for  over  a  year).  However,  we  found  several 
problems  with  the  forms. 

a.  Cost 

A  significant  amount  of  time  Is  required  to  perform  the  analysis 
necessary  to  complete  the  forms.  We  estimate  that  It  will  take  approximately 
50  hours  per  1000  lines  of  code  to  properly  complete  the  forms  (from 
requirements  through  testing  and  Integration).  For  large  projects.  It  Is 
possible  that  the  full-time  services  of  one  engineer  would  be  required  to 
perform  only  this  analysis.  The  amount  of  detail  required  by  the  forms  Is 
unreasonable,  and  the  cost  of  providing  the  detail  far  outweighs  the  benefits 
obtained . 
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b.  Applicability  to  CAMP 


Since  the  CAMP  software  Is  a  collection  of  reusable  parts  rather 
than  a  complete  software  system,  a  majority  of  the  Items  requested  were  not 
applicable.  The  rationale  for  requiring  the  CAMP  project  to  complete  the 
Software  Measurement  forms  was  to  measure  various  aspects  of  reusability  In 
order  to  measure  a  component's  reuse  potential.  However,  only  one  of  the  six 
forms  makes  any  mention  of  reuse  potential. 

In  addition,  the  forms  assume  that  formal  configuration  control 
exists  Since  CAMP  Is  a  research  project,  this  type  of  environment  was  not 
practical . 

c.  Instructions 

The  directions  for  completion  of  the  forms  are  generally  quite 
poor.  Often  the  directions  for  an  Item  simply  restate  the  question  rather 
than  explain  what  Is  wanted.  For  example.  In  the  Completeness  section  of  the 
Software  Evaluation  Report  (Prelim),  the  question  Is  asked:  "How  many  data 
references  are  identified?"  Instead  of  explaining  what  Is  wanted,  the 
directions  state:  "Enter  the  number  of  data  references  that  are  Identified." 

In  addition,  only  two  of  the  six  forms  have  a  glossary,  and  only  one 
has  a  list  of  acronyms.  The  Inclusion  of  these  two  Items,  and  possibly  a 
sample  completed  form,  would  be  a  useful  addition  to  the  Instructions. 

d.  Exposure  of  Contractor's  Proprietary  Data 

Certain  requested  Items  (In  particular,  cost  data)  could  expose  a 
contractor's  proprietary  data.  An  example  of  such  a  request  is  found  In 
Resource  Expenditure  Detailed  Report,  which  asks  for  both  labor  hours  and 
labor  cost,  which  Indirectly  exposes  a  contractor's  labor  rate.  Such 
questions  should  be  removed  from  the  form  or  assurances  should  be  given  to 
contractors  that  tills  data  will  be  secure  In  the  STARS  database. 
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e.  Subjectivity  of  Requested  Data 


The  data  requested  by  the  forms  Is  often  of  a  subjective  nature. 
The  usefulness  of  this  type  of  data  Is  highly  questionable. 

2.  COMMENTS  ON  SPECIFIC  FORMS 

The  following  paragraphs  contain  comments  specific  to  each  of  the  six 
forms. 


a.  Resource  Expenditure  Detailed  Report 

This  form  details  a  contractor's  Incurred  resource  expenditure  for 
software  development  In  a  particular  project.  It  Is  completed  at  the 
beginning  and  end  of  each  software  development  activity.  On  the  CAMP  project 
this  translated  to  four  submittals: 

•  Start  of  Requirements  Analysis, 

•  End  of  Requirements  Analysis, 

•  Start  of  Preliminary  Design,  and 

•  End  of  Preliminary  Design. 

The  Information  requested  by  this  form  Is  objective,  quantitative 
Information  and  the  format  Is  relatively  clear.  As  mentioned  earlier,  labor 
hours  and  labor  dollars  are  requested,  thus  exposing  a  company's  labor  rate. 
In  addition,  one  of  the  Items  requested  Is  computer  cost.  This  Is  not 
applicable  for  organizations  which  set  up  a  pool  for  buying  equipment,  since 
a  cost  per  CPU  time  unit  Is  not  computed. 

b.  Software  Development  Environment  Summary  Report 

This  form  describes  the  environment  In  which  the  software  Is  being 
developed  and  Is  completed  at  the  beginning  of  each  software  development 
activity.  It  requests  Information  about  the  project's  software 
configuration,  development  site,  design  methods,  personnel,  and  communication 
techniques.  The  CAMP  project  submitted  this  form  at  the  beginning  of 
Requirements  Analysis  and  at  the  beginning  of  Preliminary  Design. 
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No  problems  were  found  with  this  form.  The  Information  requested 
was  objective  and  easily  obtained. 

c.  Software  Characteristics  Detailed  Report 

This  form  requests  detailed  software  characteristic  Information  at 
every  level  (CSCI,  TLCSC,  Unit).  The  CAMP  project  submitted  this  form  at  the 
end  of  Requirements  Analysis  and  at  the  end  of  Preliminary  Design. 

This  form  required  the  largest  amount  of  time  to  complete  because  of 
the  detail  requested.  Almost  20  hours  was  spent  completing  the  two 
submissions  required  on  the  CAMP  project;  It  Is  staggering  to  think  of  the 
amount  of  time  which  will  be  required  on  a  large  project.  The  following 
paragraphs  contain  comments  on  some  of  the  sections. 

The  second  question  of  Section  M,  which  requests  unit 
characteristics,  requires  the  use  of  a  Halstead  Software  Science  Retries 
tool,  but  this  Is  not  mentioned  anywhere  In  the  documentation.  The  cost  of 
developing  such  a  tool  and  completing  the  analysis  for  each  unit  would  be  a 
significant  load  on  a  project. 

Section  F,  Quality  Factor  Requirements,  gives  three  choices,  "High", 
"Medium",  and  "Low",  for  a  series  of  questions.  A  fourth  choice  Is  needed 
between  "High"  and  "Medium"  to  describe  the  situation  In  which  a  quality 
factor  Is  highly  emphasized  but  not  quantified,  since  many  of  the  factors 
described  are  not  quantifiable  when  developing  reusable  software.  In 
addition,  this  section  Is  highly  subjective. 

d.  Software  Change  /  Error  Document 

This  form  requests  detailed  Information  on  the  changes  and  errors 
that  occur  In  a  CSCI.  The  CAMP  program  submitted  this  form  at  the  end  of 
Requirements  Analysis,  but  we  challenge  Its  applicability  In  our  case.  Since 
we  did  not  baseline  our  requirements  until  the  end  of  requirements  analysis. 
It  Is  Incorrect  to  say  that  we  had  any  errors.  In  addition,  since  CAMP  Is  a 
research  project,  we  did  not  exercise  formal  configuration  control,  which  Is 
something  that  this  form  assumes. 


10? 


This  form  Is  most  applicable  to  a  system  that  Is  already  deployed,  or  In  the 
test  and  Integration  phase. 

e.  Software  Evaluation  Report  (Req)  and  Software  Evaluation  Report 
(Prelim) 


These  forms  request  an  evaluation  of  the  software  at  the  end  of 
Software  Requirements  Analysis  and  Preliminary  Design,  respectively.  They 
collect  data  In  28  software-oriented  classification  areas.  The  CAHP  project 
submitted  Software  Evaluation  Report  (Req)  at  the  end  of  Requirements 
Analysis  and  Software  Evaluation  Report  (Prelim)  at  the  end  of  Top-Level 
Design. 

Many  of  the  forms  strayed  from  objectivity,  but  these  two  forms  were 
the  worst  offenders,  requesting  vague  and  subjective  Information.  For 
example,  one  of  the  questions  In  Req  Is:  "Are  there  requirements  to  organize 
and  distribute  Information  within  the  CSCI?" 

In  addition,  most  of  the  questions  were  not  applicable  to  CAHP, 
since  they  referred  to  Implementation  dependent  details.  For  example,  Prelim 
asks  for  processing  time,  memory  space  used,  etc.  Only  a  few  sections  of 
these  forms  will  yield  valid  data  on  the  reusability  of  CAMP  parts. 

In  addition,  these  forms  use  the  word  "all"  too  often  In  questions. 
For  example,  one  of  the  questions  In  Prelim  Is:  "Does  the  design  provide 
Interface  compatibility  among  all  processors,  communication  links,  memory 
devices,  and  peripherals?"  This  requirement  would  be  unattainable,  and 
therefore  the  answer  to  a  question  such  as  the  above  could  not  be  "Yes". 
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SECTION  VIII 

REUSABLE  SOFTWARE  PARTS  CONCLUSIONS 


This  section  discusses  some  of  the  conclusions  reached  during  CAMP  as 
they  relate  to  the  Issues  of  commonality  and  parts.  Conclusions  from  the 
CAMP  Software  Parts  Composition  study  are  discussed  In  Volume  II. 

Sufficient  commonality  does  exist  (albeit  well  disguised)  within  missile 
software  systems  to  Justify  the  development  of  reusable  software  parts. 

CAMP  Identified  over  200  reusable  software  parts  for  the  missile  software 
domain.  The  parts  identified  range  from  very  simple  mathematical  functions 
to  complex  processes  and  structures.  The  existence  of  these  parts 
demonstrates  that  commonality  does  exist.  It  Is  our  belief  that  most 
embedded  reai  time  software  systems  have  an  equivalent  amount  of  commonality. 

The  proper  performance  of  a  domain  analysis  Is  the  single  most  Important 
step  In  a  software  reusability  program.  The  Identification  of  meaningful 
reusable  software  parts  Is  highly  dependent  upon  a  detailed  analysis  of  the 
target  domain  by  Investigators  skilled  In  the  design  of  software  parts  and  In 
the  application  area.  It  Is  especially  critical  In  real-t  ne  embedded 
software  systems  to  avoid  the  temptation  to  propose  software  parts  without 
conducting  this  type  of  analysis  or  the  parts  that  are  developed  will  likely 
not  be  reusable  and/or  efficient. 

Commonality  exists  at  many  levels.  The  Identification  of  functional 
commonality  Is  typically  not  difficult.  However,  the  team  conducting  the 
domain  analysis  must  he  sensitive  to  the  existence  of  the  higher  levels  of 
commonality  (l.e  ,  pattern  and  architectural  commonality)  In  order  to 
maximize  the  number  and  value  of  parts. 

There  Is  some  commonality  which  cannot  be  captured  In  Ada.  Although 
the  generic  facility  in  Ada  Is  a  mechanism  which  Is  Invaluable  In  developing 
reusable  software  parts,  by  Itself  It  Is  not  enough.  There  exist  significant 
types  of  commonaMty  which  cannot  be  Implemented  by  means  of  generics.  What 
Is  needed  Is  some  type  of  system  (eg.  an  expert  system)  In  which  design 
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paradigms  and  rules  for  building  components  from  these  paradigms  can  be 
expressed. 

Reusable  software  parts  are  feasible  for  the  missile  software 
domain.  The  feasibility  of  developing  software  parts  for  the  missile  domain 
was  established  by  showing  that  Ada  could  be  used  to  develop  parts  which  were 
reusable  across  a  wide  spectrum  of  missile  applications,  and  sufficiently 
efficient  for  embedded  real-time  applications.  The  CAMP  parts  were  designed 
so  that  they  were  as  efficient  as  an  application-specific  Ada  software 
component  written  by  an  Ada  expert. 

Reusable  parts  can  be  built  which  are  both  simple  to  use  and 
powerful.  Classically,  software  engineers  have  had  to  compromise  between 
making  parts  which  were  simple  to  use  or  which  were  powerful  (l.e.,  allowed 
the  user  a  high  level  of  control).  The  design  of  the  CAMP  parts  demonstrated 
that  when  the  advanced  features  of  Ada  are  carefully  used,  parts  can  be  built 
which  appear  simple  to  the  user.  In  addition,  the  parts  can  be  used  by  many 
different  levels  of  user.  The  casual  user  can  allow  the  part  to  use  defaults 
(unseen  to  him),  the  stringent  user  can  override  defaults  to  achieve  a  level 
of  control  over  the  behavior  of  the  parts. 

Developing  good  reusable  parts  will  cost  more  (approximately  10 
percent  -  15  percent)  than  developing  an  equivalent  amount  of 
application-specific  code.  The  effort  required  to  develop  parts  which  are 
reusable,  efficient,  and  simple  to  use  Is  higher  than  the  effort  required  to 
develop  one-shot  software.  Although  parts  can  be  developed  cheaply,  good 
parts  (l.e.,  parts  which  have  a  high  degree  of  reusability,  efficiency,  and 
simplicity)  require  special  expertise  and  extra  attention. 

Software  parts  have  significant  potential  for  Increasing  software 
development  productivity.  Section  V  of  this  report  established  the 
beneficial  Impact  that  software  parts  can  have  on  software  productivity. 

When  amortized  across  a  non-trlvlal  number  of  applications,  the  cost  to 
develop  and  maintain  software  parts  should  be  greatly  outweighed  by  the  cost 
savings  associated  with  using  the  parts. 
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Software  parts  should  be  strongly  data  typed.  On  the  surface,  the  use 
of  strong  data  typing  In  reusable  software  parts  for  embedded  real-time 
software  systems  does  not  appear  pract1cal--but  this  Is  not  the  case.  If  a 
non-generic  subprogram's  parameters  are  strongly  typed  (e.g.,  typing  a 
distance  parameters  for  a  computation  only  In  feet),  then  the  generality  of 
the  part  Is  lost  (e.g.,  the  part  cannot  be  used  with  parameters  In  meters). 

If  a  generic  approach  Is  used,  then  all  Internal  computation  must  be  generic 
functional  parameters  to  allow  for  different  typing  of  the  data  (e.g.,  If  a 
part  needs  to  multiply  a  speed  parameter  by  a  time  parameter  and  we  wish  the 
user  to  have  the  flexibility  of  specifying  the  units  of  the  speed  and  time 
parameters,  then  the  multiply  operator  will  need  to  be  a  generic  functional 
parameter).  The  requirement  to  supply  a  large  number  of  such  generic 
functional  parameters  can  become  excessive.  Yet,  having  strong  data  typing 
provides  valuable  protection  against  misusing  the  part  (e.g.,  If  a  part 
requires  a  parameter  In  feet  It  will  not  accept  a  parameter  of  type  meters). 
One  solution  which  was  developed  on  CAMP  was  to  use  the  generic  approach, 
but,  to  have  many  of  the  generic  functional  parameters  default  to  operations 
provided  by  the  same  packages  which  supplied  the  data  types.  In  other  words, 
a  package  which  defines  speed  In  feet  per  second  and  time  In  seconds  would 
also  overload  the  multiplication  operator  to  return  a  distance  type  In  feet. 
All  of  this  Is  Invisible  to  the  user,  unless  he  wants  to  override  the 
defaulting  mechanism. 

Software  reuse  Is  not  an  all  or  nothing  process.  Although  the  Ideal 
goal  In  developing  reusable  software  parts  Is  to  have  parts  which  can  always 
be  used  exactly  as  they  exist  (l.e.,  with  no  modification),  the  value  of 
software  reusability  Is  not  dependent  upon  achieving  this  goal  completely. 

If  a  user  has  to  modify  the  parts  slightly,  there  Is  still  a  great  benefit  In 
using  the  parts.  Another  way  of  saying  the  same  thing  Is  that  a  part  which 
Is  close  to  what  a  user  wants  Is  better  that  starting  from  scratch.  We 
should  not  become  such  purist  that  we  lose  sight  of  the  pragmatic  value  of 
such  parts. 

Software  parts  should  be  developed  by  a  project-directed  parts  group. 
Figure  57  depicts  three  approaches  to  developing  software  parts.  The 
autonomous  parts  group  approach  has  the  disadvantage  that  It  Is  easy  for  the 
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parts  group  to  develop  parts  which  are  not  needed  or  are  not  usable  by  the 
projects.  The  disadvantage  of  the  project  spin-off  approach  Is  that  projects 
seldom,  If  ever,  have  the  additional  resources  needed  to  develop  good  parts 
(remember  that  It  will  cost  more  to  develop  a  good  reusable  part).  The  Ideal 
approach  to  Institutionalizing  the  development  of  parts  appears  to  be  the 
project-directed  parts  group.  In  this  approach,  the  parts  group  receives 
part  suggestions  or  even  draft  parts  from  projects  and  they  develop  the 
part.  Concurrently,  they  study  specified  domains  (which  have  been  selected 
by  the  projects  as  being  of  high  value)  and  the  work  of  the  parts  group  Is 
reviewed  by  the  projects. 


PROJECT  SPIN-OFF 


figure  57:  Approaches  to  Developing  Software  Parts 
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The  ultimate  success  of  a  parts  approach  to  software  engineering  Is 
dependent  upon  the  establishment  of  a  software  parts  engineering 
discipline.  The  use  of  software  parts  will  not  come  naturally  to  most 
organizations,  lo  overcome  the  Initial  reluctance  to  use  parts  and  to 
maximize  the  use  of  parts,  four  things  are  needed. 

a.  Management  commitment  to  spur  the  Introduction  of  parts  In  the 
software  engineering  process. 

b.  Tools  to  automate  the  mechanical  chores  associated  with  the  use  of 
par ts . 

c.  Knowledge  about  what  parts  are  available  and  how  they  should  be  used. 

d.  The  enforcement  of  a  discipline  which  will  ensure  that  parts  are 
used  when  possible,  and  are  used  correctly. 
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CAMP  MISSILE  SOFTWARE  SET 

This  appendix  contains  brief  descriptions  of  the  ten  missile  software  systems 
used  In  the  CAMP  domain  analysis. 


ID  .  AGM- 109H 

Name  .  Medium  Range  Alr-to  Surface  Missile 

Launch  Platform  ...  Surface  Ship  and  Submarine 

Target  Type  .  Extended  Ground  Targets 

Warhead  .  Cc  ntlonal,  Multiple 

Sponsor  .  Air  Force 

Host  Computer  .  Class  II  Digital  Integrating  Subsystem  (OIS)  Computer 


ID  .  AGM-109L 

Name  .  Medium  Range  Alr-to  Surface  Missile 

Launch  Platform  ...  Aircraft 

Target  Type  .  Land  and  Sea  Targets 

Warhead  .  Conventional,  Unitary 

Sponsor  .  Air  Forre 

Host  Computer  .  Class  II  Digital  Integrating  Subsystem  (OIS)  Computer 


10  .  UTG  SINP 

Name  . 

Unaided  Tactical  Guidance  Strapdown  Inertial  Navigation  Program 
Launch  Platform  ...  N/A 

Target  Type  .  N/A 

Warhead  .  N/A 

Sponsor  .  Air  Force 

Host  Computer  .  MDAC  Model  771  processor 
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ID  .  MGD-GANP 

Name  .  Midcourse  Guidance  Demonstration  Guidance  and  Navigation 

Program 

Launch  Platform  ...  N/A 

Target  Type  .  N/A 

Warhead  .  N/A 

Sponsor  .  Air  Force 

Host  Computer  .  Class  I  Digital  Integrating  Subsystem  (DIS)  Computer 


ID  .  BGM-109A 

Name  .  Tomahawk  Land  Attack  Missile 

Launch  Platform  ...  Surface  Ship  or  Submarine 

Target  Type  .  Ground  Based 

Warhead  .  Nuclear 

Sponser  .  JCMPO 

Host  Computer  .  Litton  LC4516C 


ID  .  BGM-109B 

Name  .  Tomahawk  Anti-Ship  Missile 

Launch  Platform  ...  Surface  Ship  or  Submarine 

Target  Type  .  Surface  Ship 

Warhead  .  Conventional ,  Unitary 

Sponsor  .  JCMPO 

Host  Computer  .  IBM  SP-0 


ID  .  BGM-109C 

Name  .  Tomahawk  Land  Attack  Missile 

Launch  Platform  ...  Surface  Ship  or  Submarine 

Target  Type  .  Ground  Based 

Warhead  .  Nuclear 

Sponsor  .  JCMPO 

Host  Computer  .  Litton  LC4516C 
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ID  .  BGM-109G 

Name  .  .  Tomahawk  Land  Attack  Missile 

launch  Platform  ...  Ground  Based  CWCW 

Target  lype  .  Ground  Based 

Warhead  .  Nuclear 

Sponsor  .  JCMPO 

Host  Computer  .  Litton  LC4516C 


Name  .  Harpoon  Missile  (1C) 

Launch  Platform  ...  Surface  Ship,  Submarine,  Aircraft 

Target  Type  .  Surface  Ship 

Warhead  .  Conventional,  Unitary 

Sponsor  .  Navy 

Host  Computer  .  Mldecourse  Guidance  Unit 


Name  .  SPARTAN 

Launch  Platform  ...  Ground  Based 

Target  Type  .  Ballistic  Missile 

Sponsor  .  Army 
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APPENDIX  B 


THE  CAMP  SOFTWARE  PARTS  TAXONOMY 


Figure  8  1  deplctr.  the  CAMP  software  parts 
(l.e.,  classes)  In  this  taxonomy  are  described 


taxonomy.  Each  of  the  taxa 
In  the  following  subsections. 


•  DATA  PACKAGE  PARTS 

•  PROCESS  MANAGEMENT  PARTS 

DATA  CONSTANT  PARTS 

-  ASYNCHRONOUS  CONTROL  PARTS 

-  DATA  TYPES  PARTS 

-  COMMUNICATION  PARTS 

•  EQUIPMENT  INTERFACE  PARTS 

•  MATHEMATICAL  PARTS 

GENERAL  PURPOSE  EQUIPMENT  INTERFACE  PARTS 

-  COORDINATE  ALGEBRA  PARTS 

SPECIFIC  EQUIPMENT  INTERFACE  PARTS 

-  MATRIX  ALGEBRA  PARTS 

-  QUATERNION  ALGEBRA  PARTS 

•  PRIMARY  OPERATION  PARTS 

-  TRIGONOMETRIC  PARTS 

!  NAVIGATION  PARTS 

-  DATA  CONVERSION  PARTS 

KALMAN  FILTER  PARTS 

-  SIGNAL  PROCESSING  PARTS 

-  GUIOANCE  b  CONTROL  PARTS 

-  POLYNOMIAL  PARTS 

-  NON-GUIDANCE  CONTROL  PARTS 

-  GENERAL  MATH  PARTS 

•  ABSTRACT  MECHANISM  PARTS 

ABSTRACT  DATA  STRUCTURE  PARTS 

ABSTRACT  PROCESS  PARTS 

- 

•  GENERAL  UTILITY  PARTS 

F  igure  B-l .  CAMP  Software  Parts  Taxonomy 
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1 .  DATA  PACKAGE  PARTS 


These  are  parts  which  encapsulate  related  data  Items. 

1.1  Data  Type  Parts 

These  are  parts  which  provide  cohesive  sets  of  Ada  data  types  ( 1 . e . 
the  characterization  of  data  values  and  applicable  operations)  to  the  user. 

A  package  containing  the  data  types  used  within  a  specific  coordinate  system 
would  be  an  example  of  this  type  of  part. 

1.2  Data  Constant  Parts 

These  are  similar  to  data  type  packages  except  they  provide  cohesive 
sets  of  Ada  data  constants  (l.e.,  data  objects  with  fixed  values)  to  the 
user.  A  package  containing  constant  earth  data,  such  as  earth  radius  and 
gravity  coefficient,  would  be  an  example  of  this  type  of  part. 

2.  EQUIPMENT  INTERFACES  PARTS 

These  are  parts  which  provide  standard  Interfaces  for  peripheral 
equipment. 

2.1  General  Purpose  Equipment  Interfaces  parts 

These  are  parts  which  provide  Interface  to  general  classes  of 
equipment.  Some  examples  of  this  type  of  part  would  be  an  Interface  to  a 
generic  radar  altimeter  or  an  Interface  to  a  generic  data  bus. 

2.2  Specific  Equipment  Interfaces  Parts 

These  are  arts  which  provide  Interfaces  to  specific  hardware 
devices,  such  as  an  Interface  to  a  HIL-STD-1553B  data  bus. 
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3.  PRIMARY  OPERATION  PARTS 


These  are  parts  which  provide  the  operational  requirements  capabilities. 

3.1  Navigation  Parts 

These  are  parts  which  provide  the  functions  required  to  navigate  a 
missile  (l.e.,  determine  Its  position  and  velocity). 

3.2  Kalman  Filter  Parts 

These  are  parts  which  provide  the  functions  required  to  Implement 
Kalman  Filters. 

3.3  Guidance  &  Control  Parts 

These  are  parts  which  provide  functions  for  guiding  and  controlling 
the  missile  (e.g.,  lateral  guidance,  vertical  guidance,  autopilot,  etc.). 

3.4  Non-Guidance  Control  Parts 

These  are  parts  which  provide  control  functions  for  non-guidance 
areas  such  as  fuel  control,  air  data  control,  seeker  control,  etc. 

4.  ABSTRACT  MECHANISM  PARTS 

These  are  parts  which  provide  mechanisms  for  Implementing  various 
abstract  data  structures  and  processes. 

4.1  Abstract  Data  Structures  Parts 

These  are  parts  which  provide  mechanisms  for  Implementing  high  level 
data  objects.  For  example,  various  types  of  queues  such  as  FIFO  and  LIFO 
queues,  would  be  Implemented  by  this  type  of  part. 
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4.2  Abstract  Process  Parts 


These  are  parts  which  provide  abstract  processes  such  as  event 
sequencers,  finite  state  machines,  etc. 

5  PROCESS  MANAGEMENT  PARTS 

These  are  parts  which  provide  function  for  managing  the  asynchronous 
behavior  of  a  missile  software  system  and  the  communication  between  tasks. 

5.1  Asynchronous  Control  Parts 

These  are  parts  which  provide  the  facilities  needed  to  control  the 
asynchronous  behavior  of  the  software  processes.  In  essence,  they  give  the 
programmer  the  capability  of  specifying  the  asynchronous  aspects  of  missile 
flight  software  separate  from  Its  functional  aspects  and  at  a  much  higher 
level  of  abstraction. 

5.2  Communication  Parts 

These  are  parts  which  provide  the  facilities  needed  to  control  data 
based  communications  between  and  within  processes.  A  part  which  provides 
mutual  update  exclusion  protection  between  data  which  Is  shared  by  two  or 
more  asynchronous  processes  would  be  an  example  of  this  type  of  part. 

6.  MATHEMATICAL  PARTS 

These  are  parts  which  provide  a  wide  variety  of  relatively  standard 
mathematical  operations. 

6.1  Coordinate  Algebra  Parts 

These  are  parts  which  provide  operations  on  3  dimensional  coordinate 

vectors. 
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6.2  Matrix  Algebra  Parts 


These  are  parts  which  provide  standard  matrix  and  vector  operations 
(e.g.,  multiplication,  cross-products,  etc.). 

6.3  Quaternion  Algebra  Parts 

These  are  parts  which  provide  standard  quaternion  operations. 

6.4  Trigonometric  Parts 

These  are  parts  which  provide  the  standard  trigonometric  operations 
(e.g.,  sine,  cosine,  etc.). 

6.5  Data  Conversion  Parts 

These  are  parts  which  provide  operations  for  converting  data  from 
one  form/unit  to  another. 

6.6  Signal  Processing  Parts 

These  are  parts  which  provide  signal  processing  functions  such  as 
filters  and  limiters. 

6.7  Polynomial  Parts 

These  are  parts  which  provide  polynomial  functions  which  can  be  used 
for  a  variety  of  operations  (e.g.,  building  special  purpose  trigonometric 
functions,  etc.) 
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6.8  General  Nath  Parts 


These  are  general  purpose  math  parts  useful  In  a  variety  of 
situations  (e.g.  Interpolation  tables,  change  accumulators,  etc.). 

7.  GENERAL  UTILITIES  PARTS 

These  are  parts  which  provide  general  facilities  such  as  memory 
declassification,  memory  checksum,  etc. 
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APPENDIX  C 
CAMP  PARTS  LIST 


This  appendix  contains  a  list  of  parts  Identified  during  the  CAMP 
project.  The  parts  are  listed  by  category  and  subcategory.  The  part  number 
Is  a  unique  number  used  for  Identification  purposes.  The  column  entitled 
Schematic  Only  refers  to  whether  a  part  consists  only  of  a  part  constructor 
or  whether  there  Is  also  an  underlying  part  that  Is  available  separately  from 
the  constructor. 
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CATEGORY 

MCATEOONT 

PANT  « 

NME 

Schematic  Only 

Data 

Constanta 

•017 

WGS72  Ellipsoid  Oats  (Petrie  Version) 

No 

Data 

Constants 

•oia 

WGS72  Ellipsoid  Data  (Engineering  Version) 

No 

Data 

Constants 

•019 

WGS72  Unftless  Ellipsoid  Data 

No 

Data 

Constants 

•070 

Universal  Constants 

No 

Data 

Constants 

•  158 

Conversion  factors 

No 

Data 

Types 

•021 

•asic  Data  Types 

No 

Data 

Typ** 

•023 

Kalman  filter  Data  Types 

No 

Data 

type* 

•  163 

Autopilot  Data  Types 

No 

Oata 

Types 

•236 

Data  Type  Constructor 

res 

Equipment  Interface 

General  Purpose 

•  169 

Missile  Radar  Altimeter  Handler 

NO 

Equipment  Interface 

General  Purpose 

*042 

Missile  Radar  Altimeter  Handler  with  Auto  Power  On 

NO 

Equipment  Interface 

General  Purpose 

•043 

•us  Interface  Constructor 

Yes 

Equipment  Interface 

General  Purpose 

•046 

Clock  Handler 

No 

Navigation 

Wander  Azimuth 

•  185 

Compute  East  Velocity 

No 

Navigation 

Wander  Azisuth 

•  186 

Compute  North  Velocity 

NO 

Navigation 

Wander  Azimuth 

•001 

Cospute  Earth  Relative  Horizontal  Velocities 

NO 

Navigation 

Cannon 

•002 

Altitude  Integration 

NO 

Navigation 

Common 

•003 

Compute  Ground  Velocity 

No 

Navigation 

Wander  Azimuth 

•004 

Compute  Total  Angular  Velocity 

No 

Navigation 

Common 

•005 

Compute  Gravitational  Acceleration 

NO 

Nevigat ion 

Common 

•006 

Cospute  Gravitational  Acceleration  from  Sin  LAT 

No 

Navigation 

Wander  Azisuth 

•007 

Compute  Coriolis  Acceleration 

NO 

Navigation 

Wander  Azimuth 

•  187 

Compute  Coriolis  Acceleration  from  Total  Rates 

No 

Nevigat ion 

North  Pointing 

•008 

Compute  Coriolis  Acceleration 

No 

Navigation 

Common 

•009 

Compute  Heading 

No 

Navigation 

Common 

•010 

Update  Velocity 

NO 

Navigation 

Common 

•039 

Compute  Scalar  Velocity 

NO 

Navigation 

Wander  Azimuth 

•035 

Cospute  Radii  of  Curvature 

No 

Navigation 

North  Pointing 

•036 

Compute  Radii  of  Curvature 

NO 

Navigat ion 

North  Pointing 

•012 

Compute  Total  Platform  Rotation  Rates 

NO 

Navigation 

Wander  Azimuth 

•Oil 

Compute  Total  Platform  Rotation  Rates 

NO 

Navigat  ion 

Common 

•  157 

Compute  Rotational  Increments 

NO 

Navigation 

North  Pointing 

•014 

Compute  Earth  Rotation  Rate 

No 

Navigation 

Wander  Azimuth 

•013 

Compute  Earth  Rotation  Rate 

NO 

Navigation 

Wander  Azimuth 

•025 

Compute  Earth  Relative  Rotation  Rates 

No 

Navigation 

North  Pointing 

•026 

Compute  Earth  Relative  Rotation  Rates 

NO 

Navigation 

North  Pointing 

•027 

Latitude  Integration 

No 
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CATEGORY 

SUBCATEGORY 

PART  # 

NAME 

Schemata 

Navigation 

Wander  Ailmuth 

R029 

Conpute  latitude 

No 

Navigation 

Wander  Azimuth 

ROJO 

Confute  Latitude  using  Arctangent 

No 

Navigation 

North  Pointing 

R031 

longitude  Integration 

No 

Navigation 

Wander  Azimuth 

R033 

Confute  longitude 

No 

Navigation 

Wander  Azimuth 

R028 

Coafute  Wander  Azimuth  Angle 

No 

Navigation 

Cannon 

R032 

Initialize  Direction  Cotine  Matrix 

No 

Navigation 

Cannon 

R0J4 

Trapeziodal  Integration 

No 

Navigation 

North  Pointing 

R016 

North  Pointing  Navigation  Brndte 

No 

Navigation 

Cannon 

Rise 

Common  Navigation  Bundle 

No 

Navigat ion 

Wander  Aziauth 

R01S 

Wander  Angle  Navigation  Bundle 

No 

Navigat ion 

Common 

R237 

Navigation  Component  Constructor 

Yes 

Navigation 

Common 

R238 

Navigation  Subsystem  Constructor 

Yes 

Kalman  Fitter 

General 

*145 

Propogate  State  Transition  and  Process  Noise  Matrices 

No 

Kalman  filter 

General 

R146 

Propogatt  Error  Covariance  Matrix 

NO 

Kalman  Filter 

Genera  t 

R147 

Kalman  Update 

No 

Kalman  Fitter 

General 

R14- 

Propogate  State  Transition  Matrix 

No 

Kalman  Filter 

General 

R149 

Compute  Kalman  Gains 

NO 

Kalman  Filter 

General 

R150 

Update  Error  Covarlanca  Matrix 

No 

Kalman  Filter 

General 

R151 

Update  State  Vector 

No 

Kalman  Fitter 

General 

R152 

Sequentially  Update  Covariance  Matrix  and  State  Vector 

No 

Kalman  F i Iter 

General 

*153 

Kalman  Executive 

No 

Kalman  Filter 

Complicated  H 

*181 

Kalman  Update 

No 

Kalman  Fitter 

Complicated  N 

R182 

Compute  Kalman  Gain 

No 

Kalman  F i Iter 

Complicated  H 

R1A3 

Update  Error  Covariance  Matrix 

No 

Kalman  filter 

Complicated  H 

R184 

Update  State  Vector 

No 

Kalman  Filter 

Complicated  H 

R201 

Sequentially  Update  Covariance  Matrix  and  State  Vector 

No 

Nath 

Coordinate  Algebra 

*047 

Coordinate  Algebra  Bundle 

No 

Math 

Coordinate  Algebra 

R050 

Vector  Vector  Addition 

No 

Nath 

Coordinate  Algebra 

*205 

Sparse  Right  X  Vector-Vector  Addition 

NO 

Math 

Coordinate  Algebra 

*206 

Sparse  Right  Z  Vector-Vector  Addition 

No 

Math 

Coordinate  Algebra 

*051 

Vector  Vector  Subtraction 

No 

Math 

Coordinate  Algebra 

R207 

Sparse  Right  XT  Vector-Vector  Subtraction 

No 

Math 

Coordinate  Algebra 

*052 

Vector  Vector  Dot  Product 

No 

Math 

Coordinate  Algebra 

*208 

Vector  length 

No 

Math 

Coordinate  Algebra 

R053 

Vector  Vector  Cross  Product 

No 

Math 

Coordinate  Algebra 

*054 

Vector  Scalar  Multiplication 

No 

Math 

Coordinate  Algebra 

*209 

Sparse  X  Vector -Scaler  Multiplication 

No 
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CATEGOtY 

MCATEGOtY 

PANT  1 

NAME 

Scheaietic  Only 

Hath 

Coordinate  Algebra 

*055 

Vector  Scalar  Division 

NO 

Nath 

Coordinate  Algebra 

1049 

Natrix  Vector  Multiplication 

NO 

Nath 

Coordinate  Algebra 

*056 

Matrix  Scalar  Multiplication 

NO 

Nath 

Coordinate  Algebra 

*057 

Matrix  Scalar  Division 

NO 

Nath 

Coordinate  Algebra 

*060 

Matrix  Scalar  Addition 

NO 

Nath 

Coordinate  Algebra 

*067 

Matrix  Scalar  Stbtractlon 

No 

Nath 

Coordinate  Algebra 

*066 

Matrix  Matrix  Multiplication 

No 

Nath 

Coordinate  Algebra 

*070 

Natrix  Matrix  Addition 

No 

Nath 

Coordinate  Algebra 

*071 

Matrix  Matrix  Subtraction 

NO 

Nath 

Coordinate  Algebra 

*072 

Set  to  Identity  Matrix 

NO 

Nath 

Coordinate  Algebra 

*078 

Set  to  Zero  Matrix 

NO 

Nath 

Matrix  Algebra 

*058 

Matrix  Algebra  Package 

NO 

Nath 

Matrix  Algebra 

*061 

Vector  Vector  Addition 

NO 

Nath 

Matrix  Algebra 

*062 

Vector  Vector  Subtract  ion 

No 

Nath 

Matrix  Algebra 

*063 

Vector  Vector  Dot  Product 

No 

Nath 

Matrix  Algebra 

*104 

Vector  Length 

No 

Nath 

Matrix  Algebra 

*065 

Vector  Scalar  Multiplication 

NO 

Nath 

Matrix  Algebra 

*066 

Vector  Scalar  Division 

No 

Nath 

Matrix  Algebra 

*069 

Matrix  Vector  Multiplication 

No 

Nath 

Matrix  Algebra 

*073 

Matrix  Scalar  Multiplication 

No 

Nath 

Matrix  Algebra 

*074 

Matrix  Scalar  Division 

No 

Nath 

Matrix  Algebra 

*075 

Matrix  Scalar  Addition 

NO 

Nath 

Matrix  Algebra 

*076 

Natrix  Scalar  Subtraction 

NO 

Nath 

Natrix  Algebra 

*077 

Matrix  Matrix  Multipl  i cat  ion 

NO 

Nath 

Matrix  Algebra 

*079 

Matrix  Matrix  Addition 

NO 

Nath 

Natrix  Algebra 

*060 

Matrix  Natrix  Subtraction 

NO 

Nath 

Natrix  Algebra 

*155 

Set  to  Identity  Natrix 

No 

Nath 

Natrix  Algebra 

*156 

Set  to  Zero  Matrix 

No 

Nath 

Natrix  Algebra 

*210 

Statically  Sparse  Natrix  Constructor 

Tes 

Nath 

Natrix  Algebra 

*226 

Define  Dynamically  Sparse  Matrix 

No 

Nath 

Matrix  Algebra 

*211 

Define  Symmetric  (Half  Storage)  Matrix 

No 

Nath 

Natrix  Algebra 

*227 

Define  Symmetric  (Full  Storage)  Matrix 

NO 

Math 

Matrix  Algebra 

*212 

Define  Diagonal  Matrix 

NO 

Nath 

Matrix  Algebra 

*235 

General  Purpose  Natrix  Constructor 

YtS 

Nath 

Geometric 

*081 

Ceometric  Package 

NO 

Math 

Geometric 

*082 

Compute  Angle  Setueen  Headings 

NO 

Nath 

Trigonometric 

*083 

Nadfan  Tr igonoawtrlc  Package 

No 
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CATEGORY 

SUBCATEGORY 

PART  # 

NAME 

Schemat 1 1 

Math 

Trigonometric 

ROSA 

Degree  Trigonometric  Package 

No 

Hath 

Trigonometric 

ROSS 

Semicircte  Trigonometric  Package 

No 

Math 

Trigonometric 

R086 

Sine 

NO 

N«th 

Trigonometric 

R087 

Cosine 

No 

Math 

Trigonometric 

ROM 

Tangent 

No 

Math 

Trigonometric 

R089 

Arcsine 

NO 

Math 

Trigonometric 

R090 

Arccosine 

NO 

Math 

Trigonometric 

R091 

Arctangent 

NO 

Math 

Trigonometric 

R092 

Sine 

No 

Math 

Trigonometric 

ROW 

Cosine 

NO 

Math 

trigonometric 

R094 

Tangent 

No 

Math 

Trigonometric 

ROW 

Arcsine 

NO 

Math 

Trigonometric 

R096 

Arccosine 

NO 

Math 

Trigonometric 

R097 

Arctangent 

NO 

Math 

Trigonometric 

R098 

Sine 

No 

Math 

Trigonometric 

R099 

Cosine 

No 

Math 

Trigonometric 

R100 

Tangent 

No 

Math 

Trigonometric 

RIOT 

Arcsine 

No 

Math 

Trigonometric 

RIO? 

Arccosine 

No 

Math 

Trigonometric 

R103 

Arctangent 

NO 

Math 

Data  Conversion 

R105 

Unit  Conversion 

NO 

Math 

Date  Conversion 

R106 

External  form  Conversion 

No 

Math 

Signal  Processing 

RT07 

Signal  Processing  Package 

NO 

Math 

Signal  Processing 

RIOS 

Limiter 

No 

Math 

Signal  Processing 

R037 

limiter 

No 

Math 

Signal  Processing 

ROM 

Limiter 

No 

Math 

Signal  Processing 

R160 

Limiter 

NO 

Math 

Signal  Processing 

R 1 09 

General  1st  Order  filter 

No 

Math 

Signal  Processing 

R161 

Tustin  Lead-Lag  Filter 

No 

Math 

Signal  Processing 

R110 

Second  Order  filter 

NO 

Math 

Signal  Processing 

till 

Filter  Coefficient 

No 

Math 

Signal  Processing 

R162 

Tustin  Lag  filter 

No 

Math 

Signal  Processing 

R202 

Absolute  Limiter  with  flag 

NO 

Math 

Signal  Processing 

R203 

Tustin  Integrator  with  Limit 

No 

Math 

General  Purpose 

R1 12 

General  Nath  Package 

No 

Math 

General  Purpose 

R113 

Change  Calculator 

NO 

Math 

General  Purpose 

RTH 

Accumulator 

NO 
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CATEGOtT 

SUBCAT  £  GO*  Y 

PART  f 

NAME 

Schematic  Only 

Nath 

General  Purpose 

R1T5 

Change  Accumulator 

No 

Hath 

General  Purpose 

H1 16 

Interpolation 

No 

Math 

General  Purpose 

HI  17 

Extrapolation 

No 

Math 

General  Purpose 

H 1 10 

Interpolation  Table 

No 

Math 

General  Purpose 

*119 

Interpolation  Table 

No 

Math 

General  Purpose 

*120 

Increment or 

No 

Math 

General  Purpose 

HT21 

Decrement or 

No 

Math 

General  Purpose 

H  T  22 

Absolute  Value 

No 

Math 

General  Purpose 

*224 

Sion 

No 

Math 

General  Purpose 

*123 

Square  Root 

No 

Nath 

General  Purpose 

*124 

Integrator 

No 

Math 

General  Purpose 

*142 

Running  Average 

No 

Math 

General  Purpose 

*143 

Mean  Absolute  Difference 

No 

Nath 

General  Purpose 

*144 

Mean  Value  of  a  Vector 

No 

Nath 

Polynomial 

*213 

Table  Loofci^ 

No 

Math 

Polynomial 

*214 

Chebyahev 

No 

Nath 

Polynomial 

*215 

f  ike 

NO 

Nath 

Polynomial 

*216 

Hart 

NO 

Nath 

Polynomial 

*217 

Hastings 

No 

Math 

Polynomial 

*218 

Least  Squares 

No 

Nath 

Polynomial 

*219 

Legendre 

NO 

Math 

Polynomial 

*220 

Modified  Newton*Raphson 

NO 

Math 

Polynomial 

*221 

Neuton-Raphson 

NO 

Math 

Polynomial 

*222 

Taylor  Series 

No 

Math 

Polynomial 

*223 

System  Functions 

NO 

Abstract  Mach an ism 

Data  Structure 

*125 

FIFO  Buffer 

No 

Abstract  Mechanism 

Oata  Structure 

*126 

Circular  Buffer 

NO 

Abstract  Machanitai 

Data  Structure 

*164 

FIFO  Buffer 

NO 

Abstract  Machanitai 

Data  Structure 

*165 

Priority  Oueue 

NO 

Abstract  Machanitai 

Data  Structure 

*166 

Stack 

NO 

Abstract  Machanitai 

Data  Structure 

*167 

Unbounded  Stack 

NO 

Abstract  Machanitai 

Process 

*127 

Finite  State  Machine  Constructor 

Yes 

Abstract  Machanitai 

Process 

*126 

Meaty  Machine  Constructor 

Tes 

Abstract  Machanitai 

Process 

*129 

Event  Driven  Sequencer  Constructor 

Tes 

Abstract  Mechanism 

Process 

*130 

Tima  Drivan  Sequencer  Constructor 

Yet 

Abstract  Machanitai 

Process 

*159 

Sequence  Controller  Constructor 

Yes 

Process  Managfant 

Asynchronous  Control 

*131 

Process  Controtlar  Constructor 

Yes 
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Process  Management 

Asynchronous  Control 

*132 

Aperiodic  Task  Shell  Constructor 

Yes 

Process  Management 

Asynchronous  Control 

*133 

Continuous  Task  Shall  Constructor 

Yes 

Process  Management 

Asynchronous  Control 

*134 

Periodic  Task  Shell  Constructor 

Yes 

Process  Management 

Asynchronous  Control 

*135 

Data  Driven  Task  Shell  Constructor 

Yes 

Process  Management 

Contnunication 

*  1 36 

Messaga  Checksum 

No 

Process  Management 

Communication 

*137 

Update  Exclusion 

No 

General  Utility 

*138 

Memory  Checksu* 

No 

General  Utility 

*139 

Memory  Checks  us 

No 

General  Utility 

*140 

Memory  Declassification 

No 

General  Utility 

*141 

Instruction  Set  Test 

No 

General  Utility 

*239 

Generic  Instantiation  Constructor 

Yes 

Guidance  1  Control 

Autopilot 

*048 

Integral  Plus  Proportional  (IPP)  Gain 

No 

Guidance  i  Control 

Autopi lot 

*059 

Pitch  Autopilot 

No 

Guidance  i  Control 

Autopilot 

*064 

lattral/Directional  Autopilot 

No 

Guidance  A  Control 

Waypoint  Steering 

*168 

Coeputa  Unit  Radial  Vector 

No 

Guidance  A  Control 

Waypoint  Steering 

*169 

Computa  Segment  Unit  Normal  Vector 

No 

Guidance  A  Control 

Waypoint  Steering 

*170 

Initialite  Steering  Vectors 

No 

Guidance  A  Control 

Waypoint  Steering 

*171 

Update  Steering  Vectors 

No 

Guidance  A  Control 

Waypoint  Steering 

*172 

Computa  Turn  Angle  and  Direction 

NO 

Guidance  A  Control 

Waypoint  Steering 

*173 

Compute  Crosstrack  and  Heading  Error  when  Turning 

NO 

Guidance  A  Control 

Waypoint  Steering 

*174 

Compute  Crosstrack  and  Heading  Error 

NO 

Guidance  A  Control 

Waypoint  Steering 

*175 

CoNputt  Crosstrack  and  Heading  Error  when  not  Turning 

No 

Guidance  A  Control 

Waypoint  Steering 

*176 

Computa  Distanca  to  Currant  Waypoint 

No 

Guidance  A  Control 

Waypoint  Steering 

*177 

Computa  Turning  and  Honturning  Distances 

No 

Guidance  A  Control 

Waypoint  Steering 

*178 

Perform  Stop  Turn  Test 

NO 

Guidance  A  Control 

Waypoint  Steering 

*179 

Perform  Start  Turn  Tast 

NO 

Guidance  A  Control 

Waypoint  Steering 

*180 

Perform  Start/Stop  Turn  Taat 

No 

Non- Guidance  Control 

Air  Oate 

*228 

Coeputt  Outside  Air  Temperature 

NO 

Non-Guidance  Control 

Air  Data 

*229 

No 

Non-Guidance  Control 

Air  Data 

*230 

Computa  Mach 

No 

Non-Guidance  Control 

Air  Data 

*231 

Computa  Dynamic  Pressure 

No 

Non-Guidance  Control 

Air  Data 

*232 

Coaputa  Spaed  of  Souid 

NO 

Non-Guidance  Control 

Air  Data 

*233 

Computa  Barometric  Altitude 

No 

Non-Guidance  Control 

fuel  Consumption 

*234 

Mach  Control 

NO 

219 
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APPENDIX  D 

EVALUATION  OF  DOD-STD-2167  ANO 
ASSOCIATED  DID'S 


1.  Introduction  .  129 

2.  General  Applicability  of  DOD-STD-2167  _  131 

3.  Specific  Applicability  to  Reusable 

Software,  Expert  Systems  and  Ada  .  135 

4.  The  Software  Requirements  Specification  ..  139 

5.  The  Software  Top-Level  Design  Oocument  ...  141 

6.  The  Software  Detailed  Design  Document  -  143 

7.  Coding  Standards  for  Ada  .  143 

8.  Recommendations  .  148 


1 .  INTRODUCTION 

The  standard  for  Defense  System  Software  Development  (OOD-STO-2467) 
successfully  establishes  a  complete  life-cycle  process  for  developing  and 
maintaining  Mission-Critical  Computer  Software.  It  provides  a  uniform  method 
for: 

a.  generating  d1ffer;nt  types  and  levels  of  software  and  documentation; 

b.  applying  development  tools,  approaches  and  methods;  and, 

c.  planning  and  controlling  projects. 

The  Data  Item  Descriptors  (DID's)  which  accompany  the  standard  provide 
adequate  guidelines  for  recording  and  communicating  the  Information  generated 
during  the  software  development  process. 

One  of  the  major  tasks  of  the  CAMP  effort  was  the  application  of 
MIL-STD-2167  to  the  development  of  a  reusable  parts  library  and  an  automated 
parts  engineering  system.  The  standard  Is  not  directed  at  the  development  of 
reusable  software,  expert  systems,  or  Ada-based  systems.  The  application  of 
2167  required  the  CAMP  team  to  tailor  the  requirements  of  the  standard  to 
meet  the  particular  needs  of  each  of  these  three  areas. 
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While  the  standard  Is  adequate  for  defining  the  development  process  of 
some  aspects  of  reusable  software,  the  specification  and  design  of  CAMP  parts 
according  to  2167  posed  some  difficulties.  The  specification  must  Inform  the 
part  designer  and  user  of  what  the  part  accomplishes  functionally  and  also 
provide  performance  Information  about  the  part.  The  fact  that  CAMP  Is 
concerned  with  reusable  software  does  not  significantly  change  this 
activity.  The  standard  does  not  establish  the  exact  meaning  of  a  Computer 
Software  Configuration  Item  (CSCI)  for  reusable  software,  nor  does  It  define 
the  meaning  of  a  software  part.  In  addition,  the  specification  must  provide 
an  environment  for  the  part,  describing  the  dependencies  which  exist  between 
parts.  The  top-level  design  must  describe  the  architecture  of  the  system  and 
Its  decomposition  Into  components,  detailing  the  Interfaces  between 
components.  Both  the  top-level  and  detailed  design  must  describe  global 
processing  and  output  for  each  component  as  well  as  major  entitles  which  are 
local  to  the  component.  DOD-STD-2167  was  not  Intended  to  address  these 
Issues  for  reusable  software. 

Following  DOD-STO-2167  for  the  development  of  expert  systems  raised  other 
Issues  during  the  CAMP  study.  The  development  process  for  these  systems  does 
net  follow  the  traditional  top-down  approach.  Major  requirements  for 
fundamental  system  functions  of  the  expert  system  are  not  decomposed  Into 
subordinate  units,  except  for  general  utilities,  such  as  creating  relations 
or  updating  a  data  base.  These  system  functions  rely  on  Inference  mechanisms 
built  Into  an  expert  system,  and  are  usually  recursive  Lisp-based 
operations.  The  process  of  developing  the  knowledge  base,  the  set  of  rules 
for  driving  the  expert  system,  Is  also  not  covered  by  2167,  but  It  Is  clearly 
a  system  requirement. 

Software  developed  using  Ada  Is  also  not  addressed  by  the  standard.  The 
Joint  Logistics  Commanders  Computer  Software  Management  Subgroup  Is  currently 
developing  a  revision  to  the  standard  to  Incorporate  the  use  of  Ada  Into  the 
development  process.  The  use  of  Ada  on  CAMP  established  several  areas  of  the 
standard  which  the  revision  process  must  address.  These  Include  Ada 
constructs  such  as  packages  and  generics,  as  well  as  the  concept  of  data 
typing. 
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This  Appendix  will  present  an  overview  of  OOO-STO-2167,  comparing  It  to 
previous  standards,  and  assessing  Its  general  applicability  to  the 
development  of  mission-critical  software.  It  will  also  describe  the 
application  of  the  standard  to  the  development  of  reusable  software  parts, 
the  development  of  the  expert  system,  and  the  use  of  Ada  for  the  CAMP  study. 

A  section  of  the  Appendix  will  describe  each  of  the  three  OIO's  which  apply 
to  CAMP  documents  and  their  appropriateness  to  the  documentation  of  CAMP 
software.  The  final  section  of  the  Appendix  discusses  the  design  and  coding 
standards  of  DOD-STD-2167  and  the  top-level  design  and  detailed  design 
headers  developed  for  CAMP  Ada  designs. 

2.  GENERAL  APPLICABILITY  OF  DOD-STD-2167 

Current  and  future  Government  software  projects  will  require  contractors 
to  meet  the  new  Defense  System  Software  Development  standards  of 
DOD-STD-2167.  The  standard.  Issued  on  June  4,  1985,  supersedes  the  previous 
standard  for  software  development,  D0D-STD-1679A.  Associated  with 
DOD-STD-2167  are  several  Data  Item  Descriptions  (DID's)  which  define  the 
documentation  requirements  for  Government  contracted  software  projects. 

These  DID's  supersede  those  associated  with  1679A  and  they  also  supersede 
several  DID's  associated  with  other  military  standards,  such  as  the  A,  B5, 
and  C5  specifications  of  MIL-STD-490,  and  the  Part  I  and  Part  II 
specifications  of  MIL-STD-483.  The  new  standard  makes  some  significant 
changes  In  the  software  development  and  documentation  process,  but  leaves 
other  areas  relatively  unchanged. 

Perhaps  the  most  Important  difference  between  2167  and  1679A  Is  that  2167 
requires  a  formal  Software  Specification  Review  (SSR),  whereas  1679A  did 
not.  The  purpose  of  the  SSR  Is  to  determine  whether  the  Software 
Requirements  Specification  (SRS),  the  Interface  Requirements  Specifications 
(IRSs),  and  the  Operational  Concept  Document  (OCO)  form  a  satisfactory  basis 
for  proceeding  Into  preliminary  software  design.  This  extra  formal  review 
may  have  a  substantial  Impact  on  software  requirements  costs.  However,  these 
costs  could  conceivably  be  made  up  during  later  phases  because  the  SSR  and 
associated  baselining  will  tend  to  make  the  software  requirements  more 
stable.  The  new  review  will  prevent  the  Introduction  of  new  requirements  or 
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changes  to  old  requirements  emerging  from  a  Preliminary  Design  Review  and 
often  not  completed  until  the  time  of  the  Critical  Design  Review,  forcing 
major  changes  late  In  a  program. 

The  following  Is  a  list  of  other  requirements  In  2167  which  are  not 
mentioned  In  1679A. 

a.  Use  approved  structured  tools  and/or  techniques  for  requirements 
analysis. 

b.  Utilize  a  Program  Design  Language  (POL)  or  other  top-level  design 
tool  for  preliminary  design. 

c.  Incorporate  human  factors  engineering  principles  In  preliminary  and 
detailed  design. 

d.  Employ  a  Program  Design  Language  during  detailed  design. 

e.  Establish  Software  Development  Files  (SDFs)  for  all  units. 

f.  Utilize  approved  coding  standards  which  may  be  those  of  the 
contractor. 

g.  Use  Independent  personnel  for  CSCI  testing  and  quality  evaluations. 

h.  Establish  a  Software  Development  Library  (SDL). 

The  documentation  required  by  the  two  standards  Is  very  similar.  A  list 
of  the  documentation  for  2167  Is  shown  In  Figure  D-l  and  a  comparison  of  the 
two  sets  of  documents  Is  shown  In  Figure  D-2.  One  difference  Is  that  2167 
requires  a  Computer  Resources  Integrated  Support  Document  (CRISD).  This 
document  describes  all  the  resources  that  are  required  to  support  the 
deliverable  software  when  It  Is  In  operation,  Including  such  things  as 
hardware,  operating  systems,  other  support  software,  personnel  required,  and 
training  programs.  Another  difference  In  the  documentation  Is  that  Software 
Trouble  Reports  and  Software  Change/Software  Enhancement  Proposals  are  no 
longer  required  as  separate  documents,  but  their  formats  are  to  be  Included 
In  the  Software  Configuration  Management  Plan. 

Redundancy  Is  a  major  weakness  of  the  primary  engineering  DID's  of 
MI L-STO-21 67 .  The  Software  Requirements  Specification,  Top-Level  Design 
Document,  and  Detailed  Design  Document,  each  restate  all  functional  areas  In 
terms  of  Input-processing-output.  The  CAMP  group  determined,  through  applying 


133 


DOO*  STD-2167  DEFENSE  SYSTEM  SOFTWARE  DEVELOPMENT  DID* 

REQUIRE¬ 

MENTS 


COOE 

CATEGORY 

NUMBER 

ACRONYM 

NAME 

Required 

Engineering 

DI-MCCR-B0008 

sss 

Sys tarn/ Segment  Specification 

Required 

Management 

DI-MCCR -80030 

SOP 

Software  Development  Plan 

I  nc  i  ude-d 

Management 

DI-MCCR -80009 

SCMP 

Software  Configuration  Management  Plan 

Included 

Management 

Dl-MCCR-80010 

SOEP 

Softwar#  Quality  Evaluation  Plan 

Included 

Management 

DI-MCCR -80011 

SSPM 

Software  Standards  and  Procaduras  Manual 

Requi red 

Engineering 

DI-MCCR -80025 

SRS 

Software  Requirements  Specification 

Included 

Engineering 

DI-MCCR -80026 

IRS 

Interface  Requiramtnta  Specification 

Required 

Engineering 

DI-MCCR-80012 

STLDO 

Software  Top  level  Design  Document 

Required 

Engineering 

DI-MCCR-80031 

SDDO 

Software  Detailed  Design  Document 

Included 

Engineering 

DI-MCCR -80027 

IDD 

Interface  Design  Document 

Included 

Engineering 

DI-MCCR -80028 

DBDD 

Data  Data  Design  Document 

Required 

Engineering 

DI-MCCR -80029 

SPS 

Software  Product  Specification 

Required 

Engineering 

Dt -MCCR-80013 

VDD 

Version  Description  Document 

Required 

Test 

DI-MCCR-800H 

STP 

Software  Test  Plan 

Required 

Test 

D! -MCCR-B001S 

STD 

Software  Test  Description 

Required 

Test 

DI-MCCR-80016 

ST  PR 

Software  Test  Procedure 

Required 

Test 

DI-MCCR -80017 

STR 

Software  Test  Report 

Vendor 

Operational 

DI-MCCR-80018 

CSOM 

Computer  System  Operator's  Manual 

Vendor 

Operational 

01 -MCCR-80019 

SUM 

Software  User's  Manual 

Vendor 

Support 

DI-MCCR -80020 

CSDM 

Computer  System  Diagnostic  Manual 

Vendor 

Support 

DI-MCCR -80021 

SPM 

Software  Progreemer's  Manual 

Vendor 

Suppo  t 

DI-MCCR -80022 

FSM 

Firmware  Support  Manual 

Required 

Operational 

DI-MCCR -80023 

OCD 

Operational  Concept  Document 

Requi red 

Support 

DI-MCCR -80024 

CRISD 

Computer  Resources  Integrated  Support  Dociment 

Requi red 

Engineering 

DI-E-3128 

ECP 

Engineering  Change  Proposal 

Requi red 

Engineering 

DI-E-3134 

SCN 

Specification  Change  Notice 

REQUIREMENTS  COOE: 

CODE  MEANING 


Required  Typically  required 

Includ'd  May  be  included  in  the 

previous  required  document 
Vendor  Mey  be  vendor  supplied 


Figure  D-l .  DOD-STD-2167  Defense  System  Software  Development  DID 1  s 
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OQDSTD-2167 

DEFENSE  SYSTEM  WniK  DEVELOPMENT  DIPS 


DIM 


D0D-STD-1679A 

NIL-STD-4C 

MIL -STD *490 

OTHER 

ACRONYM 

MAPS 

MJMSER 

MUMMER 

MUMKR 

MUMDCRS 

tss 

Systan/Sapnnt  Specification 

Dl ‘1-3101 
01*1*3117 

A  Spec 

»p 

Software  Bevel opnant  Plan 

0I-A-2176A 

D!*S*30567A 

SOtP 

Software  Configuration  Nanaganant  Plan 

D1  1*20351 

DIE2175D 

DII2177A 

Dl  E-217BA 

SOCP 

Software  Ouallty  Evaluation  Plan 

DI  R  217a 

01 *R  3521 

SSPM 

Software  Standards  and  Procedures  Manual 

SRS 

Software  Requl rename  Specification 

01-1*21340 

•1*1-31190 

01 *1*30113 

DI*E*30130A 

01*1*30139 

•9  Spec 

IRS 

Interface  Requiranents  Specification 

DI-I-213SA 

B9  Spec 

STLOO 

Software  Top  Level  Design  Docuaent 

DI-E-2130A 

C9  Spec 

SDOO 

Softwara  Oat  ailed  Design  Oocuaent 

0I-S-2139A 

C5  Spec 

100 

intarfaca  Design  Docuaent 

01E-2135A 

C5  Spec 

0100 

Oats  Sea#  Design  Docuaant 

DIS-2140A 

01-E301U 

C9  Spec 

DIE-30150 

IPS 

Softwara  Product  Spaclf (cation 

0t-S*2H1A 

Dl  *1*3126 

C5  Spec 

D I  A* 30022 

01*1*30110 

01*1*30112 

01*1*30111 

01*1*30140 

Dl *1*30145 

DIS3056D 

wo 

Version  Description  Poeuntnt 

0I-E-3121 

01*1*3122 

Dll-3123 

STP 

Softwara  Ttat  Plan 

DI-T-2142A 

01  *T -3703A 

PIT-30715 

ST0 

Softwara  Taat  Description 

DI-T-2143A 

STPR 

Softwara  Test  Procedura 

DIT214a 

Dt  1*30716 

STR 

Software  Teat  Report 

DI-T-21S6A 

DI-T-3717A 

CS0N 

Conputer  Systan  Operator's  Manual 

DI-N-2140A 

SUN 

Softwara  User’s  Manual 

DI-N-2145A 

DIN-30421 

DIM-1410 

DIN-30404 

DIN-30419 

CSOM 

Caaputar  Syatan  Diagnostic  Manual 

DIM  30422 

DI-N-30408 

SPN 

Software  Programmer's  Manual 

D 1 -M*  541 1 

m 

f inware  Support  Manual 

OCD 

Operational  Concept  Docuaent 

CRIS0 

Computer  Resources  Integrated  Scpport  Docment 

Dl-S-30569 

ICf  Engineering  Chany*  Proposal 

KM  Specification  Chang#  Not  1c# 


NOTES:  1.  Th#  2167  Software  Configuration  Menagsnant  Plan  Incorporataa  th# 

1679A  Software  Chang#/ Soft  war#  Engine  aannt  Proposal  <01  *1-2177*), 
and  th#  Computer  Software  TroU>l#  Report  (01 -E-217BA). 

2.  Th#  2167  Interface  Requlranema  Specification  and  imerfac#  Design 
Oeoawit  together  etperaeda  the  contents  of  the  167DA  Interface  Deal  pi 
Specification  <01*1 -213SA), 


Figure  D-2.  Comparison  of  DID ' s  from  DOD-STO-21 67  and  other  Standards 
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these  DIO'S  that  redundancy  could  be  avoided  by  stating  Input  processing 
output  requirements  once  In  the  Software  Requirements  Specification, 
referring  to  that  source  in  the  Top-Level  Design  Document,  and  establishing 
the  details  of  the  algorithmic  and  data  requirements  In  the  Ada  design  code 
of  the  Detailed  Design  Document.  Use  of  this  method  also  enforces 
maintenance  of  the  requirements  document,  as  the  design  Is  updated,  and 
reduces  the  likelihood  of  Introducing  errors  during  the  design  process. 

The  new  standard  concentrates  on  the  activities,  products,  reviews,  and 
baselines  that  are  required  during  each  phase  of  software  development.  It 
presents  very  little  Information  about  how  to  accomplish  these  tasks.  The 
1679A  standard  Is  much  less  clear  about  Just  what  Is  to  be  accomplished,  but 
It  presents  more  how-to  Information.  For  example, 

•  Part  of  1679A  amounts  to  a  coding  standard.  No  such  Information  Is 
present  In  the  body  of  2167,  but  a  design  and  coding  standard  Is 
Included  as  an  appendix. 

•  Details  about  how  patches  to  code  are  Identified  are  In  1679A. 

DOD-STD  2167  states  only  that  the  contractor  must  keep  track  of 
changes. 

•  Details  about  how  to  conduct  stress  testing  are  In  1679A.  These  are 
not  present  In  2167. 

•  In  requirements  analysis,  1679A  requires  diagrams  of  equipment  and 
software  relations  using  Internal  and  external  data  flow.  The  new 
standard  only  requires  that  the  contractor  use  structured 
requirements  analysis  tools  and/or  techniques. 

Functional  requirements  are  emphasized  by  1679A.  Functional, 
performance.  Interface,  and  qualification  requirements  are  treated  equally  by 
2167.  The  CAMP  study  concluded  that  this  life  cycle  approach  was  one  of  the 
strengths  of  2167 

3.  SPECIFIC  APPLICABILITY  TO  REUSABLE  SOFTWARE,  EXPERT  SYSTEMS  AND  ADA 

The  CAMP  program  was  one  of  the  first  to  apply  D00- S 1 0-21 67  to  a  complete 
software  development  process.  CAMP  Is  also  applying  Ada  under  2167.  In 
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addition,  It  Is  the  only  program  which  has  simultaneously  addressed  Issues 
raised  by  the  application  of  the  standard  to  the  development  of  a  library  of 
reusable  software  and  an  expert  system  to  support  automated  parts 
engineering.  Each  of  these  three  areas  raises  specific  Issues  about  the 
applicability  of  2167  to  particular  aspects  of  software  development. 

a.  Application  to  Reusable  Software 

The  development  of  a  library  of  reusable  software  necessitates  a 
different  approach  from  that  used  for  single-use  software.  The  Defense 
System  Software  Development  Standard  establishes  the  concept  of  a  Computer 
System  Configuration  Item  (CSCI)  as  the  basis  for  software  development  and 
defines  a  CSCI  as  Implementing  a  complete  software  subsystem.  The  standard 
specifies  that  "requirements  shall  be  derived  from  the  system  requirements  as 
defined  In  the  system/segment  specification"  for  each  CSCI  and  shall  be 
documented  In  a  Software  Requirements  Specification.  This  Specification 
shall  provide  Interface  and  data  requirements  for  the  CSCI  plus  detailed 
functional  and  performance  requirements  for  each  functional  or  structural 
component  within  the  CSCI. 

For  the  development  of  a  reusable  parts  library,  the  CSCI  consists 
of  the  requirements  derived  from  a  domain  analysis.  The  CSCI  must  meet  the 
system  requirements  of  the  entire  domain  which,  In  essence,  constitutes  the 
system/segment.  This  CSCI  will  not  meet  the  entire  software  requirements  of 
any  one  system  and  will  not  Implement  a  complete  software  subsystem.  Rather, 
the  CSCI  must  provide  parts  which  meet  requirements  common  to  a  number  of 
systems  In  the  domain  and,  together  with  custom  software,  provide  the 
capability  of  Implementing  a  software  subsystem. 

There  are  three  main  Issues  surrounding  the  development  of  the  parts 
library  within  the  CAMP  domain:  what  constitutes  a  part,  how  the  part  will 
be  used,  and  how  to  specify  a  part  so  that  It  Is  reusable.  The  first  Issue 
will  emerge  from  the  process  of  decomposing  system  specifications  Into 
parts.  The  second  Issue  will  emerge  from  creating  Ada  design  methods.  The 
third  Issue  will  depend  on  the  choice  of  a  specification  technique.  Each  of 
these  three  Issues  Is  covered  In  Section  III  of  Volume  I  of  this  report. 
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b.  Application  to  Expert  Systems 


An  expert  system  provides  extensive  mechanisms  for  facilitating 
complex  decision  making  processes.  The  two  primary  mechanisms  are  a 
Knowledge  Base  containing  the  expertise  for  a  particular  domain,  and  the 
Inference  Engine  to  draw  Inferences  using  the  knowledge  base  and  data 
supplied  by  the  user.  The  knowledge  base  Includes  facts,  rules  and 
mechanisms  for  structuring  this  knowledge. 

For  the  CAMP  program,  the  expert  system  concept  Is  applied  to  the 
process  or  automated  parts  engineering,  l.e.,  using  a  knowledge-based  system 
for  constructing  software.  The  expert  system  contains  the  knowledge  base 
which  together  with  user  Inputs  can  create  new  software,  combine  It  with 
existing  parts,  and  produce  a  new  system.  These  concepts  are  completely 
elaborated  In  Volume  II  of  this  Report. 

The  CAMP  program  tailored  DOD  STD-2167  for  the  development  of  this 
expert  system.  The  concept  of  a  CSC  I  for  an  expert  system  exists  for  system 
functions  with  regards  to  the  support  mechanisms  performing  data  base 
operations.  Other  aspects  of  the  system  functions  do  not  decompose  Into 
lower  level  components.  In  a  traditional  top-down  approach.  These  functions 
rely  entirely  on  the  Inference  mechanisms  built  Into  an  expert  system;  they 
are  recursive  routines  which  do  not  follow  the  input-processing-output 
model.  The  standard  Is  also  not  currently  Intended  for  the  development  of 
the  knowledge  base  which  Is  at  the  heart  of  an  expert  system.  Therefore,  the 
development  process  consists  of  separating  these  two  areas,  following  2167 
for  the  traditional  CSC!  aspects,  and  approaching  the  Inference  mechanisms 
and  knowledge  base  as  separate  software  requirements  areas. 

c.  Application  to  Ada 

The  use  of  UOD  SI 0-21 67  posed  some  problems  for  the  CAMP  program, 
but  they  were  expected  because  the  new  standard  does  not  specifically  address 
software  development  In  Ada.  The  Joint  Logistics  Commanders  Initiated  the 
development  of  DOP- S r D  2167  at  the  time  the  original  Ada  standard  was  under 
review.  The  Commanders  decided  at  that  time  that  Issues  of  software 
development  which  related  to  Ada  would  be  deferred  until  2167  was  published 
and  the  revision  process  began.  The  Incorporation  of  Ada  would  be  a  part  of 
that  revision  process.  Ibis  revision  process  Is  currently  In  progress. 


lhe  major  problems  In  applying  Ada  are  not  In  the  development 
process  as  much  as  In  the  documentation.  The  CAMP  program  concluded  that  Ada 
should  not  be  a  part  of  the  requirements  activity,  but  that  requirements 
should  remain  Independent  of  a  particular  Implementation.  The  Implementation 
language  Is  of  course  a  major  consideration  In  developing  requirements,  but 
the  study  concluded  that  use  of  Ada  constructs  would  restrict  the  development 
process.  Ada  Is  extremely  well  suited  to  the  software  design  process,  and 
Its  major  design  element,  the  package.  Is  central  to  the  CAMP  program.  The 
major  activities  specified  under  2167  therefore  posed  no  problems. 

Applying  Ada  under  the  DID's  of  2167  did  create  significant 
problems.  A  major  aspect  of  Ada  development  In  general,  and  reusable  parts 
in  particular.  Is  the  specification  and  design  of  data  elements.  These 
elements  consist  of  types,  constants,  and  objects  and  are  not  functional  or 
Interface  requirements.  They  do  not  fit  neatly  Into  the  Software  or 
Requirements  Specification  documents.  The  concept  of  "Input  -  Processing 
Output*  does  not  apply  because  these  data  elements  exist  Independent  of  one 
particular  function.  The  design  documents  seem  more  suited  to  a  Fortran 
implementation,  with  significant  global  data  and  minimal  concern  for  the 
implementation  at  the  design  level.  Use  of  Ada  for  design  requires  an 
essential  concern  for  the  Implementation  because  the  architectural  design 
consists  of  compilable  Ada  packages,  their  specifications  and  the 
specification  of  exported  entitles  such  as  subprograms  and  types.  With 
considerable  tailoring,  the  CAMP  program  was  able  to  make  use  of  the  design 
OIO's.  Ihese  tailoring  Issues  are  covered  below  with  specific  reference  to 
the  use  of  Ada  for  specifying  requirements,  Ada  for  design,  and  Ada  design 
and  coding  standards. 
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4.  THE  SOFTWARE  REQUIREMENTS  SPECIFICATION 


The  CAMP  program  effectively  applied  DOD-STD-2167  for  the  specification 
of  CAMP  parts  and  for  the  specification  of  most  aspects  of  the  parts 
engineering  system.  The  program  developed  Software  Requirements 
Specifications  following  the  tasks  described  under  section  5.1  of 
DOD-STD  2167.  These  Specifications  are  In  accordance  with  01- MCCR-80025, 
Software  Requirements  Specification.  The  structure  of  the  OID  required  some 
tailoring  to  address  the  Issues  discussed  above.  The  remainder  of  this 
section  summarizes  the  changes  made  by  the  CAMP  group  to  tailor  the  DID  for 
use  by  CAMP. 

The  new  standard  Is  especially  effective  In  clearly  separating  the 
requirements  and  design  activities  Into  three  distinct  areas:  software 
requirements  analysis,  preliminary  design,  and  detailed  design.  Previous 
standards  such  as  DOD  STD-1679  and  MIL-STD-483  do  not  make  this  distinction, 
and  preliminary  design  Is  subsumed  under  requirements  analysis  and  detailed 
design.  This  clear  delineation,  another  of  the  strengths  of  2167,  also  lends 
Itself  to  establishing  the  manner  In  which  Ada  should  be  applied  to  the 
documentation  process,  as  Is  discussed  below. 

a.  The  Use  of  Ada  In  the  Specifications 

The  CAMP  development  effort  demonstrated  that  the  SRS  should  be 
prepared  without  reference  to  a  specific  Ada  architecture.  While  other 
studies  have  attempted  to  use  Ada  as  a  software  requirements  language,  the 
CAMP  approach  yielded  more  generalized  requirements  specifications,  essential 
for  developing  reusable  Ada  software.  The  development  of  the  requirements 
must,  of  course,  take  cognizance  of  Ada,  to  assure  that  the  capabilities  of 
Ada  are  fully  exploited  and  to  establish  requirements  which  are  conducive  to 
Ada  Implementation.  Furthermore,  Ada  terminology  (e.g.,  tasks,  packages, 
generics)  Is  applied  wherever  appropriate.  Nonetheless,  keeping  the 
requirements  free  of  Ada  constructs  Improved  the  readability  and  utility  of 
the  parts  specifications. 

In  addition  to  documenting  specifications,  the  SRS  also  establishes 
design  guidelines,  for  the  reusable  parts  library,  designed  using  Ada,  the 
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distinction  between  requirements  and  design  allowed  CAMP  to  create  an 
architectural  design  based  on  Ada  packages.  The  top-level,  or  architectural, 
design  defines  these  packages,  their  Interfaces,  and  major  architectural 
Issues  In  the  design  of  the  package  bodies.  The  lower-level,  or  detailed, 
design  shows  the  algorithmic  design  for  subprograms  defined  In  the  top-level 
design  and  also  defines  the  subprogram  and  data  structures  which  are 
encapsulated  within  the  common  package  bodies.  These  design  Issues  are  fully 
discussed  In  Section  IV  of  Volume  I  of  this  report. 

b.  The  Input-Processing-Output  Description 

Under  DOD- STO-21 67 ,  the  Input,  processing,  and  output  sections 
document  the  processing  which  must  be  accomplished  by  the  operations  of  a 
function.  The  requirements  specification  must  define  Inputs  to  the  part  but 
they  do  not,  In  general,  establish  precise  Ada  data  types  and  they  do  not 
define  the  data  control,  l.e.,  parameter  data,  common  data,  or  local  data. 
This  precision  Is  supplied  In  the  design. 

The  SRS  for  the  parts,  and  for  the  parts  engineering  system, 
document  the  data  In  a  form  easily  recognized  by  the  designers  and  users  of 
these  systems.  This  generic  definition  Is  well  suited  to  parts  which  are  to 
be  designed  as  generic  Ada  parts,  where  the  actual  data  type  will  be  assigned 
by  the  part  user.  For  the  expert  system,  this  definition  can  be  easily 
Incorporated  Into  the  design  for  the  expert  system. 

Ada  operations  are  used  as  a  POL  In  defining  the  processing 
requirements  for  all  functions,  both  for  the  parts  and  for  the  parts 
engineering  system.  While  this  POL  definition  Is  not  a  complete  algorithmic 
description  In  most  cases,  It  does  show  the  logical  and  arithmetic  operations 
which  a  function  will  accomplish.  For  the  reusable  parts  the  exact  nature  of 
these  operations  will  be  derived  from  the  domain  analysis.  The  parts 
engineering  system  operations  come  from  the  particular  requirements  of  a 
knowledge  based  system. 

The  definition  of  output  from  a  function  will  be  similar  to  that  of 
Input.  This  data  flow  shows  the  output  but  does  not  define  the  data 
structures.  The  function's  specification  defines  the  outputs  but  does  not 
establish  data  structures  or  control.  The  design  of  the  part  will  define 
these  features. 
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c.  The  Environment  Description 


The  Software  Requirements  Specification  DID  does  not  address  the 
relationships  which  must  exist  between  parts  In  a  reusable  parts  library. 

The  CAMP  parts  are  not  Intended  for  stand-alone  use.  They  must  be  combined 
Into  larger  contexts  for  effective  utilization.  However,  the  specific 
requirements  for  a  part  cannot  assume  the  existence  of  the  lower-level 
packages.  A  user  may  wish  to  use  the  CAMP  navigation  packages,  but  not  want 
to  use  the  CAMP  data  types.  The  statement  of  a  part  environment  will 
establish  the  context  of  a  given  part,  Independent  of  other  CAMP  parts.  The 
environment  may  Include  a  description  of  constants  or  of  data  types  which  are 
required  by  a  part.  For  those  parts  requiring  special  processing,  the 
environment  may  Indicate  external  subprograms  which  must  exist  for  the  part 
to  function.  Finally,  the  environment  may  establish  the  data  which  must  be 
supplied  for  Initialization  of  the  state  of  a  given  part.  Indicating  that  the 
part  may  be  designed  as  a  generic. 

5.  THE  SOFTWARE  TOP-LEVEL  DESIGN  DOCUMENT 

The  DID  for  the  Software  Top-Level  Design  Document  establishes  this 
document  as  describing  the  structure  and  organization  of  a  particular  CSCI. 
The  document  establishes  the  Top  Level  Computer  Software  Components  (TLCSC's) 
and  the  Interfaces  between  these  components.  This  document  Is  sufficient  for 
the  top  level  design  of  the  parts  engineering  system  by  limiting  the  context 
of  design  to  the  support  functions  and  by  not  employing  Ada  for  design. 

Ihe  document  does  not  meet  all  the  documentation  needs  of  the  reusable 
parts  design.  The  documentation  of  the  Top-Level  design  for  the  CAMP  parts 
must  describe  the  architecture  of  part  packages  and  detail  the  Interfaces 
between  packages.  This  will  require  TLCSC's  which  address  the  following 
Issues : 


•  The  package  context  (the  list  of  external  packages  which  are 
needed) 

•  The  decomposition  of  the  TLCSC  Into  LLCSC's 

•  Ada  Design  of  the  specification  of  the  TLCSC  and  Its  LLCSC's 

•  Major  entitles  which  are  local  to  the  package  body 

•  Externally  callable  entries  (where  tasking  Is  used) 

•  Requirements  for  Instantiation  and  other  use  of  a  part 

•  Global  processing  and  output 

These  requirements  must  be  met  both  In  the  TLDD  and  In  the  header  of  the 
design  code  Itself. 

The  DID  Software  Top-Level  Design  Document  does  not  adequately  cover 
these  Issues.  As  described  above,  the  DID  seems  to  be  directed  towards  a 
design  which  features  data  passing  through  shared  data,  rather  than  parameter 
passing,  and  parameterless  subroutines  employed  for  structural  reasons, 
rather  than  functional  or  object-oriented  decomposition.  This  architecture 
for  a  TLCSC  Is  not  compatible  with  the  object-oriented  nature  of  an  Ada 
package  specification.  Therefore,  the  TLDD  Is  not  sufficient  for  our 
documentation  needs. 

Much  of  the  Information  that  properly  belongs  to  a  TLCSC  designed  using 
Ada  has  been  placed  In  the  Software  Detail  Design  Document  (e.g.,  the  TLCSC 
decomposition,  and  LLCSC  Interfacing).  The  CAMP  project  has  determined  that 
this  Information  must  appear  In  the  top-level  design  description.  This  will 
require  that  the  DID  for  top-level  design  be  modified  to  Include 
architectural  Information  highlighting  the  structure  of  the  TLCSC  down  to  the 
unit  level,  where  units  are  externally  callable.  It  should  also  Include 
structural  Information  which  Is  required  for  the  detailed  design  of  these 
external  Interfaces.  In  Ada  terms,  the  TLDD  will  document  the  Ada 
specification  plus  major  data  structures  and  processing  needs  of  the  package 
body. 

The  documentation  of  the  top-level  design,  will  In  general  refer  back  to 
the  Software  Requirements  Specification  for  the  top-level  algorithmic 
description.  This  should  be  sufficient  Information  for  the  needs  of  detailed 
design,  to  avoid  redundancy  between  the  SRS  and  the  TLDD.  For  algorithms 
which  have  not  been  adequately  documented  In  the  SRS,  especially  those  In  the 
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domain  Independent  area,  the  TLOD  must  Include  Input-processing-output 
Information . 

6.  THE  SOFTWARE  DETAILED  DESIGN  DOCUMENT 

The  DID  for  the  Software  Detailed  Design  Document  establishes  this 
document  as  describing  In  detail  the  organization  and  structure  of  a 
particular  CSCI.  This  document  contains  data  generated  under  the  work  task 
described  by  sections  5. 3. 1.2  and  5. 3. 2. 3  of  DOD-STD- 21 67 ,  Defense  System 
Software  Development.  CAMP  produced  a  detailed  design  for  the  reusable  parts 
only. 

The  CAMP  program  tailored  the  structure  of  this  DID  to  meet  the  needs  of 
reusable  software  components.  The  DID  Is  Intended  for  use  In  describing  the 
design  of  a  single  application  Computer  Software  Configuration  Item  (CSCI). 
The  DID  has  been  tailored  for  describing  the  design  of  parts  used 
Individually  or  on  a  group  basis.  In  addition,  elements  of  this  DID  were 
already  Incorporated  Into  the  paragraph  structure  of  the  Software  Top  Level 
Design  Document  as  explained  above. 

The  detailed  design  continued  the  application  of  Ada  for  design  which 
began  under  top  level  design.  At  the  detailed  level,  the  Ada  consists  of  the 
representation  In  Ada  of  all  algorithms  specified  in  the  SRS,  plus  any 
support  processing  which  the  top  level  design  requires.  At  this  level,  the 
directions  of  the  DID  are  adequate  for  the  detailed  design  process.  The  DIO 
does  not  adequately  address  specific  Ada  features,  such  as  the  Ada  package 
body,  but  tailoring  the  DID  to  satisfy  these  features  Is  not  a  significant 
Issue,  lhls  contrasts,  of  course  with  the  major  changes  made  In  the 
top-level  design. 

7.  CODING  STANDARDS  FOR  ADA 

Several  problems  exist  In  the  coding  standards  developed  under 
DOD-STD-2167  when  applied  to  Ada.  These  problems  are  summarized  In  Figure 
D-3.  The  standard  also  establishes  data  to  be  Included  In  code  headers. 

Code  headers  developed  ny  the  CAMP  program  for  Ada  design  used  In  the 
top-level  and  detailed  design  appear  on  the  following  pages. 


OOD-STD-2167 
PARA.  # 


DISCUSSION 


All  This  format  Is  only  applicable  to  task  bodies,  subprogram 

bodies,  and  the  block  containing  a  sequence  of  statements  at 
the  end  of  a  package  body.  It  does  not  adequately  address 
Ada  specification. 

30.3.2  The  for  clause  Is  not  explicitly  named.  This  paragraph  could 
mention  that  the  for  clause  Is  a  variation  of  do  while. 

30.3.3. d  Unique  names  cannot  apply  where  overloading  Is  used. 

30.3.3. e  This  "standard  format"  precludes  the  use  of  declare  blocks  In 

Ada. 

30.3. 3.  f  This  cannot  apply  to  task  bodies  If  they  are  to  be  considered 

a  unit. 

30.3.5  Language  "keywords"  In  Ada  may  be  construed  as  Including 
system-defined  Identifiers  (e.g.,  those  defined  In  package 
STANDARD).  These  Identifiers  must  be  overloadable. 

30.3.6  Ada  requires  "mixed-mode"  operations  In  some  cases.  (See 
package  CALENDAR.)  It  allows  other  mixed-mode  operations  for 
arithmetic  operators  via  overloading  those  defined  In  package 
STANDARD. 

30.3.8  Nesting  In  Ada  may  Include  nested  packages,  tasks,  etc.  Ooes 
this  nesting  guideline  apply  to  Ada  units  or  to  nesting  of 
expressions  (loop,  If  ...  then,  etc.)  within  a  unit? 

Figure  D-3.  Problems  In  Applying  DOD-STD-2167  Coding  Standards  to 
Ada  Design 
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a.  Ceslgn  Code  Header  Information  for  Top  Level  Design 
TLCSC  Name 

The  name  shall  be  descriptive  of  the  processing  performed  by  the 
TLCSC. 

TLCSC  Identification  Number 

The  design  identification  number  used  to  identify  the  TLCSC  for 
configuration  management 

Detailed  overview  of  TLCSC  purpose. 

for  generic  units  this  section  shall  also  provide  details  of  the 
capabilities  provided  by  generic  parameters  (analogous  to  states 
of  operation) 

Requirements  trace 

Document  SRS  requirements  met  by  the  TLCSC. 

Hay  reference  a  block  diagram  to  Illustrate  source  of  Inputs  and 
destination  of  outputs  of  TLCSC.  Diagram  should  show  allocation 
of  CSCI  requirements. 

Context  of  TLCSC 

Describe  context  of  TLCSC  (packages  which  are  wlthed,  or  are 
otherwise  visible  and  are  referenced  In  the  TLCSC).  Describe 
what  services  of  these  packages  (data  types,  objects,  functions) 
are  used  lhls  will  describe  global  data  used  by  the  TLCSC. 

Exported  Entitles 

Describe  data  objects,  data  types,  subprograms  and  packages 
defined  by  the  TLCSC.  Summarize  In  tabular  form  to  show  services 
exported  by  the  II  CSC.  Also,  describe  In  detail  all  exported 
entitles : 

Data  objects 

Describe  data  objects  exported  by  the  TLCSC.  This  shall 
Include : 

»  Name  of  object 

•  Type  of  data 

•  Value  If  a  constant 

•  Brief  description  of  data 

Data  types 

Describe  data  types  exported  by  the  TLCSC.  This  shall 
i  nc 1 ude : 

•  Name  of  type 

•  Range  of  type 

•  Predefined  operators 

•  Special  operators 

»  Brief  description  of  type 

Subprograms 

Describe  the  decomposition  of  the  TLCSC  Into  processing 
entitles  which  shall  become  Lower  Level  CSC's  and  units,  for 
each  LLCSC  or  unit  defined  by  the  decomposition  provide  the 
following  Information: 
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•  Name 

•  Abstract  describing  purpose  of  subprogram.  For 
generic  subprograms  this  shall  Include  details  of  the 
capabilities  provided  by  generic  parameters. 

•  Requirements  trace 

•  Input  data  (parameters  or  global  data) 

•  Processing  algorithms 

•  Error  conditions  not  handled  Immediately  by  the  entity 

•  Outputs  (parameters  or  global  data) 

Packages 

Describe  the  decomposition  of  the  TLCSC  Into  packages  which 
shall  become  Lower-Level  CSC's  and  units.  For  each  package 
defined  by  this  decomposition  provide  the  following 
Information: 

•  Name 

•  Abstract  describing  purpose  of  subprogram.  For 
generic  subprograms  this  shall  Include  details  of  the 
capabilities  provided  by  generic  parameters. 

•  Requirements  trace 

•  Entitles  exported 

Local  Entitles 

Describe  the  following  entitles  which  will  be  local  to  the  TLCSC: 

•  Local  data  structures,  encapsulated  In  the  package  body. 

•  Files  or  data  bases  used  by  the  TLCSC  and  not  by  any  other 
TLCSC 

•  Data  types  defined  local  to  the  TLCSC  and  not  used  by  any 
other  TLCSC. 

•  Generic  subprograms  or  packages  defined  local  to  the  TLCSC 
and  used  by  entitles  exported  by  the  TLCSC. 

Provide  Information  describing  the  use  of  these  local  entitles  by 
other  entitles  within  the  TLCSC 

Additional  "coding"  Information 

•  Security  level 

None 

Confidential 

Secret 

•  Calling  sequence 

•  History 

Prepared  by 
Baseline  data 

•  Revision  History 

Revised  by 
Revision  date 

Revision  reason:  brief  description 
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b.  Design  Code  Header  for  Detailed  Design 
LLCSC/Unlt  Name 
LLCSC/Unlt  Number 
Purpose 

Requirements  Trace 

Utilization  of  other  elements  (Types,  Procedures,  Generics,  from  other 
packages) 

Data  Specification 
Generic  Parameters 

Name  Type  Mode  Description 

Parameters 

Name  Type  Mode  Description 

Global  Data 

Name  Type  Source  Description 

local  Data 

Name  Type  Description 

local  Entitles  (Instantiation  or  declaration  of  program  units) 

Name  Type  Source  Description 

Exceptions 
Security 

Calling  Sequence 

History 

Prepared  By: 

Baseline  Date: 

Revision  History 
Revised  By: 

Revision  Date: 

Revision  Reason: 
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8.  RECOMMENDATIONS 


The  CAMP  program  revealed  a  number  of  areas  for  Improvements  to 
DOD-STD-2167  and  the  accompanying  DID's.  The  following  list  summarizes  these 
areas: 

a.  Develop  tailoring  guidelines  for  applying  DOD-STD-2167  to  the 
development  of  reusable  software  libraries. 

b.  Develop  tailoring  guidelines  for  applying  DOD-STO-2167  to  the 
development  of  expert  systems. 

c.  Revise  Appendix  III  of  DOD-STD-2167  to  Incorporate  coding  standards 
for  Ada  In  accordance  with  Paragraph  7  of  this  Appendix. 

d.  Revise  Software  Requirements  Specification  OID  to  take  data  typing 
Into  account. 

e.  Revise  Software  Top-Level  Design  Document  to  Include  complete 
architectural  breakdown  of  a  system  Into  Ada  package  specifications 
as  described  In  Paragraph  5  of  this  Appendix. 

f.  Revise  Software  Top-Level  Design  Document  to  refer  to  the  Software 
Requirements  Document  for  Input  -  processing  -  output  Information. 
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